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I  INTRODUCTION  AND  SUMMARY 


A.  Introduction 
1 .  General 

The  primary  objectives  of  the  research  described  in 
this  report  were  to  identify  at-sea  logistic  functions  that  can 
be  represented  within  the  framework  of  the  Balanced  Force 
Requirements  Analysis  Model  (BALFRAM)  and  to  develop  an  initial 
logistics  module  representing  at  least  one  of  these  at-sea 
logistic  functions.  In  addition,  SRI  was  to  assist  DTNSRDC  in 
implementing  BALFRAM  on  their  CDC  6000  series  computer. 

The  original  BALFRAM  was  developed  at  SRI,  under 
sponsorship  of  the  Office  of  Naval  Research,  during  the  period 
from  1967  through  1974.  The  model  is  a  deterministic,  expected 
value  model  that  permits  the  rapid  determination  of  the  numbers 
and  kinds  of  balanced  General  Purpose  Forces  necessary  to  carry 
out  specific  contingency  plans.  It  is  a  flexible  technique  to  be 
used  for  modeling  the  engagement  of  opposing  military  forces  and 
for  estimating  the  expected  value  outcome  of  such  engagements, 
thus  assisting  in  the  evaluation  of  the  relative  effectiveness  of 
alternative  force  levels,  mixes,  deployments,  and  utilizations. 
It  provides  a  unified  and  balanced  approach  to  force  analysis  by 
integrating  the  simultaneous  activities  of  land,  sea,  and  air 
forces.  It  can  therefore  be  used  to  follow  and  assess 
interactions  between  the  component  services  in  their  coordinated 
support  of  a  military  objective. 

The  original  BALFRAM  does  include  consideration  of  the 
effects  of  logistic  shortfalls  on  the  effectiveness  of  combat 
units.  However,  there  are  several  shortcomings  in  the  manner  in 
which  logistics  is  modelled  within  the  BALFRAM  structure.  The 
research  described  in  this  report  was  directed  toward  remedying 
some  of  these  shortcomings.  This  effort  was  segregated  into  two 
separate  components:  (1)  improvement  of  BALFRAM  logistics 
features,  and  (2)  development  of  a  SUPPLY  DISTRIBUTION  MODULE. 


2.  BALFRAM  Logistics  Improvement 

The  first  component  of  the  research  was  to  improve  the 
representation  of  the  logistics  functions  internally  within  the 
BALFRAM  structure.  In  the  original  BALFRAM,  logistics  was 
represented  as  a  monolithic  system  delivering  equal  quantities  of 
indistinguishable  supplies  along  a  single  pipeline.  A  combat 
unit's  effectiveness  was  then  degraded  linearly  according  to  the 
ratio  of  supplies  available  to  supplies  required.  This  approach 
did  not  consider  different  classes  of  supplies,  where  a  shortfall 
in  one  class  of  supplies  (i.e.,  ammunition)  would  have  a  markedly 
different  effect  on  combat  effectiveness  than  would  an  equal 
shortfall  in  another  class  of  supplies  (i.e,  personal 
belongings) . 

One  major  improvement  made  to  BALFRAM  was  to  allow  for 
multiple  supply  classes.  Instead  of  a  single  supply  stream, 
BALFRAM  has  been  modified  to  use  three  different  supply  classes 
to  determine  the  combat  effectiveness  of  a  specified  unit.  These 
three  classes  could  represent  bulk  POL,  ammunition,  and  other 
supplies.  Combat  effectiveness  of  a  specified  unit  is  then 
degraded  independently  according  to  the  supply  shortfall  of  each 
of  the  three  supply  classes. 

A  second  major  improvement  made  to  BALFRAM  was  to  allow 
the  user  more  flexibility  in  the  selection  of  the  transfer 
function  which  computes  a  unit's  operability  factor,  which 
reflects  its  combat  effectiveness  degradation  resulting  from  a 
supply  shortfall  in  each  of  the  three  classes  of  supplies.  This 
computation  is  now  in  a  parametric  form  where  the  user  can  select 
a  function  that  determines  the  shape  of  the  transfer  instead  of 
being  limited  to  only  a  linear  transfer  function.  Three  such 
parametric  forms  are  now  available  for  user  option:  a  polynomial 
form  (which  includes  the  linear  transfer  function),  an  S-curve 
form,  and  an  exponential  form.  These  provide  the  user  with  a 
wide  variety  of  degradation  transfer  functions  that  can  be  used 
for  specific  problems. 


The  end  result  of  this  first  component  of  the  research 
effort  is  an  updated  version  of  BALFRAM.  This  version  includes  an 
improved  representation  of  the  manner  in  which  the  logistics 
system  i3  modelled. 

3.  SUPPLY  DISTRIBUTION  MODULE  Development 

The  second  phase  of  the  research  was  directed  to  the 
problem  of  transporting  supplies  to  the  theater  area  to  meet  the 
requirements  established  in  a  BALFRAM  scenario.  As  a  separate 
adjunct  to  BALFRAM,  a  SUPPLY  DISTRIBUTION  MODULE  was  developed  to 
address  this  problem.  In  BALFRAM,  the  logistics  pipelines  are 
assumed  to  begin  at  a  supply  node  (port,  major  supply  depot, 
seaborne  mobile  logistics  group,  or  a  group  of  auxiliary  supply 
ships  servicing  a  naval  task  force).  Then,  these  pipelines  are 
assumed  to  extend  to  the  combat  units  to  be  supplied.  Supplies 
are  assumed  always  available  at  the  supply  node,  and  supply 
shortfalls  occur  only  if  there  is  insufficient  transportation 
capacity  to  move  them  to  the  combat  units.  Thus,  BALFRAM  itself 
deals  with  transporting  supplies  from  a  supply  node  and  not  with 
acquiring  and  stockpiling  the  supplies  themselves.  In  this 
sense,  BALFRAM  can  first  be  used  to  establish  the  requirements 
imposed  on  the  pipelines  providing  supplies  to  the  theater  area. 
The  SUPPLY  DISTRIBUTION  MODULE  can  then  be  used  to  determine  the 
pipeline  characteristics  necessary  to  meet  these  requirements. 

The  SUPPLY  DISTRIBUTION  MODULE  is  a  computer  program 
that  considers  a  3et  of  three  quasi-independent  supply  pipelines. 
Each  of  these  pipelines  represent  the  flow  of  one  of  three 
classes  of  supplies  (bulk  POL,  ammunition,  or  other  supplies) 
from  a  supply  source  or  depot  to  a  remote  intermediate  point 
(i.e.,  a  supply  node  in  a  BALFRAM  scenario)  that  services  a  set 
of  user  elements.  The  requirements  imposed  on  the  pipelines  are 
dictated  by  the  users'  demands,  which  can  change  over  time  in 
accordance  with  prespecified  contingency  events.  Pipeline 
operations  are  represented  by  the  periodic  scheduling  of  cargo 
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carriers  and  their  cargo  loads.  As  contingency  events  occur, 
pipeline  operations  are  modified  to  meet  the  new  demands  of  the 
users.  Because  of  the  time  lag  involved  in  adjusting  pipeline 
operations,  user  demands  may  not  be  satisfied  during  the 
transition  period.  Hence,  users  may  need  to  draw  from  reserve 
supplies. 

This  program  monitors  the  supply  levels  of  the  users 
and  the  intermediate  supply  point.  The  module  can  be  used  to 
examine  the  extent  of  user  supply  shortfalls  resulting  from 
unanticipated  contingent  activities,  or  it  can  be  used  to  apriori 
alter  pipeline  operations  in  anticipation  of  contingencies,  thus 
ensuring  sufficient  provisioning  of  users  at  all  times.  The 
module  can  be  used  in  conjunction  with  a  BALFRAM  exercise  or, 
being  separate  from  BALFRAM,  it  can  be  a  useful  tool  for  other 
analyses  concerned  with  transporting  supplies  to  remotely 
deployed  military  forces. 


4.  Report  Structure 

A  summary  of  the  results  of  this  research  is  presented 
in  the  next  section  of  this  chapter.  The  detailed  results  are 
discussed  in  succeeding  chapters.  Chapter  II  presents  an 
overview  of  BALFRAM  as  it  existed  before  to  this  research  effort. 
In  Chapter  III,  certain  shortcomings  of  the  logistics  simulation 
portion  in  BALFRAM  are  identified,  and  the  internal  improvements 
made  to  BALFRAM  to  overcome  these  limitations  are  described. 
Chapter  IV  describes  the  SUPPLY  DISTRIBUTION  MODULE  that  was 
developed  as  a  separate  adjunct  to  BALFRAM.  This  chapter 
includes  a  detailed  description  of  the  module,  including  the 
results  obtained  for  a  sample  problem.  Also,  this  chapter 
identifies  several  limitations  of  the  module  that  could  be 
overcome  by  expanding  the  module  at  a  future  date.  An  appendix 
then  follows  that  portrays  the  program  input  formats  for  the 
SUPPLY  DISTRIBUTION  MODULE,  defines  all  of  the  program 
nomenclature,  and  provides  a  complete  listing  of  the  computer 
program.  . 


B.  Summar 


1 .  BALFRAM  Overview 

BALFRAM  is  a  computer-based,  compiler-like  model  that 
can  be  tailored  to  diverse  geographies,  force  mixes,  strategies, 
tactics,  and  levels  of  aggregation.  BALFRAM  provides  an  abstract 
framework  within  which  problems  of  force  requirements  and 
capabilities  can  be  analyzed.  It  is  an  event-triggered, 
time-stepped  technique  for  modeling  the  engagement  of  opposing 
military  forces  and  estimating  the  expected  value  outcome  of  such 
engagements,  thus  assisting  in  the  evaluation  of  the 
effectiveness  of  alternative  force  levels,  mixes,  deployments, 
employments,  utilizations,  and  support  options.  BALFRAM  is  a 
two-sided  methodology  that  encompasses  Ground,  Air,  Naval,  and 
Special  Purpose  Forces. 

Geography  is  represented  in  terms  of  nodal  points  and 
lines  of  access  between  nodes,  i.e.,  a  network.  The  nodal  points 
can  represent  worldwide,  broadly  defined  geographical  areas 
(battle  zones,  supply  areas)  or  individual  locations  such  a3 
airbases,  ports  or  key  military  objectives.  Areas  represented  by 
a  node  can  range  in  size  from  that  required  for  an  Army  squad  to 
that  required  for  a  naval  or  air  battle.  The  lines  of  access 
between  nodes  represent  the  paths  over  which  the  forces  and 
logistics  of  both  sides  must  move.  These  lines  and  nodes  also 
can  reflect  strategic  movement  options  such  as  port  or  airhead 
access  rights,  air  space  overflight  restrictions  or  contested  sea 
lanes,  as  well  as  tactical  factors  such  as  military  objectives, 
roads  and  critical  river  crossings,  and  environmental  conditions. 

Force  characteristics  within  BALFRAM  are  described  by 
the  numbers,  types,  location,  and  status  of  units  that  each  side 
can  ultimately  commit  during  the  scenario.  Each  unit  is  a 
notional  concept.  Unit  sizes  can  vary  from  representing  a 
company  up  to  representing  a  theater  size  force.  Furthermore,  a 
unit  can  represent  any  of  a  variety  of  force  types.  For  instance, 

a  unit  can  represent  a  division  force  equivalent  or  several 
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divisions,  a  formation  of  aircraft,  a  ship,  or  a  large  naval 
force.  Individual  members  of  a  specific  unit  have  similar 
characteristics  such  as  combat  effectiveness,  attrition 
capability,  sustainability  and  mobility. 

The  initial  deployment  of  all  available  units  and  their 
initial  goals  are  specified  as  part  of  the  force  characteristics. 
In  addition  to  the  initial  manner  in  which  available  forces  are 
planned  to  be  employed,  it  is  sometimes  necessary  or  desirable  to 
alter  deployment  policies  or  mission  allocations  contingent  upon 
some  set  of  possible  circumstances  which  could  occur.  These 
contingent  activities  provide  a  model  of  the  operational 
priorities  and  movement  logic  that  must  govern  individual  combat 
units  as  the  scenario  progresses.  BALFRAM,  rather  than  imposing 
a  fixed  set  of  limited  contingency  rules,  allows  the  user  to 
specify  any  unique  set  of  rules  for  the  particular  problem  and 
scenario  under  study. 

The  fight  laws  used  in  BALFRAM  are  an  adaptation  of  the 
Lanchester  Law s  of  Combat.  These  laws  define  the  attrition  to 
each  side  in  an  engagement  as  a  function  of  time.  They  must  also 
permit  determination  of  the  time  needed  for  one  side  to  defeat 
the  other.  However,  BALFRAM  is  not  a  Lanchester  model  per  se; 
rather,  it  is  a  modularized  simulation  that  U3es  the  Lanchester 
laws  for  some  attrition  calculations. 

Logistics  modeling  in  BALFRAM  is  accomplished  by 
establishing  a  set  of  "pipelines"  along  which  supplies  flow  to 
designated  units.  A  pipeline  may  connect  many  nodes  and  supply  a 
large  number  of  units.  As  a  result  of  enemy  interdiction, 
pipeline  capacity  may  be  reduced.  The  effectiveness  of  the 
pipeline  supplied  units  is  then  reduced  in  proportion  to  the 
shortfall  of  supplies.  Provision  is  made  for  pipeline 
regeneration  rates,  deployment  factors,  resupply  rate  factors, 
and  designation  of  nodes  and  units  to  be  resupplied.  Logistic 
pipelines  can  represent  air,  sea,  or  land  supply  lines  and  thus 
accomodate  strategic  heavy  airlift,  bulk  or  containerized  cargo 
ships,  or  truck  convoys.  The  analyst  may  generate  pipelines  for 
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both  friendly  and  enemy  forces  and  specify  which  of  each  3ide's 
units  are  to  be  employed  in  pipeline  interdiction  roles. 

The  purpose  of  the  logistics  feature  of  BALFRAM  is  to 
impair  unit  effectiveness  when  logistical  capacity  will  not 

sustain  maximum  effectiveness.  The  main  components  of  the 
logistics  simulation  are  the  logistical  transportation  units. 
These  units  have  an  order  of  battle  measured  in  units  of 

transportation  capacity,  such  as  convoys,  cargo  ships, 
containers,  reefers,  and  the  like.  Each  unit  of  transportation 
has  a  supply  capacity.  The  fighting  units  have  a  supply 

requirement  that  is  specified  in  supplies  per  fighting  unit.  The 

logistics  pipeline  is  assumed  to  begin  at  a  supply  node  (port  or 
major  supply  depot)  and  extend  to  the  supplied  units.  Attrition 
in  the  logistics  simulation  is  assumed  to  affect  only  the 
transportation  units  in  the  pipeline,  not  the  reserve  units  or 
the  supply  node.  Supplies  are  always  available  if  transportation 
capacity  is  available  to  move  them.  BALFRAM  deals  with 
transporting  supplies,  and  not  with  acquiring  and  stockpiling. 

Resupply  of  transportation  units  occurs  at  a 
prespecified  rate  and  begins  at  a  scheduled  time.  When  there 
are  more  transportation  units  available  than  are  required  by  the 
pipeline  to  supply  the  combat  units,  the  excess  are  held  in  the 
reserve  unit  until  needed.  Thus,  the  reserve  units  build  and 
hold  any  surpluses  that  are  protected  from  attrition.  iach 
logistic  pipeline  is  assigned  a  pipeline  unit,  a  reserve  unit, 
and  a  specified  set  of  combat  units  and  nodes  to  supply.  Each 
logistics  pipeline  is  independent  of  all  other  pipelines. 

The  supply  requirements  are  computed  for  all  assigned 
combat  units  when  they  are  at  the  specified  nodes.  This  is  done 
by  multiplying  the  unit  size  by  the  required  supply  rate.  The 
sum  of  these  requirements  is  compared  with  the  supplies 
available.  The  number  of  transportation  units  available  is  the 
sum  of  the  units  in  the  pipeline  and  reserve  units.  When  the 
available  supplies  are  less  than  the  required  supplies,  the 
combat  effectiveness  of  each  supplied  unit  is  scaled  down  to  an 
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appropriate  level.  The  current  scaling  method  in  BALFRAM 
consists  of  multiplying  each  combat  unit's  firepower  potential  by 
the  proportion  of  required  supplies  that  are  available,  a 
strictly  linear  degradation. 

Another  feature  of  the  logistics  simulation  is  to 
control  combat  unit  deployment  as  a  function  of  the  availability 
of  logistics.  Deployment  of  any  combat  unit  can  be  delayed  until 
there  is  sufficient  transportation  capacity  to  accomodate  the 
units  already  deployed,  leaving  enough  capacity  to  also  supply 
any  unit  about  to  be  deployed. 

BALFRAM  has  a  number  of  features  to  select  meaningful 
output,  including  options  for  complete  battle  history,  FEBA 
movement  history,  logistic  throughput  and  interdiction  history, 
battle  node  information,  and  summaries.  Also  available  is  a 
complete  description  of  the  input  scenario:  force  structure, 

deployment,  time-phased  military  objectives,  operational  and 
support  concepts,  and  scheduling. 


2.  Logistics  Shortcomings  and  Improvements  in  BALFRAM 

There  is  general  acknowledgement  that  lack  of  logistics 
support  will  decrease  combat  unit  effectiveness.  However,  there 
is  not  agreement  on  the  quantitative  effects  on  combat  unit 
potential  that  would  result  from  logistic  support  inadequacies  of 
various  types,  such  as  supply  shortfalls  or  maintenance  system 
deficiencies.  Logistics  is  not  a  monolithic  system  delivering 
equal  quantities  of  equally  needed  supplies.  The  logistics 
system  delivers  separate  items  for  a  multitude  of  purposes. 
These  items  are  generally  grouped  into  classes  for  ease  of 
management  and  handling  such  as  bulk  POL,  ammunition,  and  other 
supplies.  The  effects  of  shortfalls  in  these  classes  on  combat 
potential  are  markedly  different,  depending  on  both  the  class  and 
the  type  of  unit  being  supplied.  The  previous  BALFRAM  version 
treats  all  supplies  as  indistinguishable  and,  therefore,  of  equal 
effect  on  the  success  of  a  combat  unit. 

One  major  improvement  in  the  present  version  of  BALFRAM 


is  the  addition  of  multiple  supply  classes.  Instead  of  a  single 
supply  stream,  BALFRAM  has  been  modified  to  use  three  supply 
classes  to  determine  the  combat  effectiveness  of  a  specified 
unit.  For  example,  the  three  classes  could  represent  bulk  POL, 
ammunition,  and  other  supplies.  Each  of  the  classes  has 
independent  transportation  capacity,  regeneration  capability,  and 
attrition.  Supply  shortfalls  in  the  three  classes  each  generate 
independent  operability  factors  that  are  combined  to  compute  the 
total  loss  of  combat  effectiveness  of  the  unit.  A  operability 
factor  is  computed  for  each  supply  class  for  each  unit  supported 
by  the  pipeline.  Pipelines  are  defined  by  the  collection  of 
units  that  are  supplied  and  the  nodes  where  those  units  must  be 
located  to  receive  those  supplies.  The  operability  factor  is 
computed  from  a  transfer  function  that  uses  the  ratio  of  supplies 
available  to  supplies  required. 

The  second  major  improvement  in  the  BALFRAM  logistics 
module  allows  more  flexibility  in  the  selection  of  the  transfer 
function  that  computes  the  operability  factor  from  the  ratio  of 
supplies  available  to  supplies  required  for  each  supply  class. 
This  computation  has  been  changed  to  a  parametric  form.  The 
user  will  not  be  limited  to  a  linear  transfer  function  but  will 
be  able  to  choose  a  function  that  determines  the  shape  of  the 
transfer.  Three  such  parametric  forms  are  now  available  for  user 
option;  a  polynomial  form,  an  S-curve  form,  and  an  exponential 
form.  These  provide  the  user  with  a  wide  variety  of  operability 
transfer  functions  that  can  be  used  for  specific  problems. 

3.  SUPPLY  DISTRIBUTION  MODULE 

A  SUPPLY  DISTRIBUTION  MODULE  was  developed  as  a 
separate  adjunct  to  BALFRAM.  This  module  addresses  the  problem 
of  transporting  supplies  to  a  theater  area.  BALFRAM  can  first  be 
used  to  establish  the  requirements  imposed  on  the  pipelines 
providing  supplies  to  the  theater  area.  The  SUPPLY  DISTRIBUTION 
MODULE  can  then  be  used  to  determine  the  pipeline  characteristics 
necessary  to  meet  these  requirements. 
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The  SUPPLY  DISTRIBUTION  MODULE  is  a  computer  program 
that  considers  a  set  of  three  quasi-independent  supply  pipelines, 
each  pipeline  representing  the  flow  of  one  of  three  classes  of 
supplies  (bulk  POL,  ammunition,  or  other  supplies)  from  a  supply 
source  or  depot  to  a  remote  intermediate  supply  point  (ISP)  that 
services  a  set  of  user  elements.  An  ISP  could  represent  a 
foreign  port,  a  remotely  located  supply  base,  a  seaborne  mobile 
logistic  force,  one  or  more  AOEs  in  company  with  a  task  group,  or 
simply  an  unattended  task  group  taken  as  a  whole.  The  user 
elements  could  represent  foreign-based  troops  drawing  supplies 
from  a  foreign  port  or  supply  base,  a  debarked  marine  force 
drawing  supplies  from  a  sea-based  logistic  support  group,  or  a 
task  group  drawing  supplies  from  underway  replenishment  ships. 

Users  are  continuously  supplied  by  their  ISP,  while  the 
ISP  is  resupplied  on  a  periodic  basis  by  cargo  carriers  (ships  or 
aircraft)  whose  cycle  time  includes  transit  time,  loading  and 
unloading  times,  preparation  time,  and  a  delay  time  for  routine 
maintenancee  and  other  activity  between  cruises  or  flights.  User 
inputs  include  an  initial  demand  rate,  a  maximum  supply  level,  a 
safety  supply  level,  a  critical  supply  level  (just  enough 
supplies  to  enable  the  user  to  withdraw  and  return  to  a  safe 
haven),  and  an  essentiality  priority  of  the  user  in  relation  to 
other  users  on  the  pipeline. 

Initially,  the  users  are  assumed  to  be  stocked  to  their 
maximum  supply  levels,  and  an  initial  pipeline  operation  is  set 
up  so  that  the  ISP  can  meet  all  the  demands  of  its  associated 
users.  ISP  inputs  include  a  maximum  storage  capacity,  an 
emergency  supply  level,  a  critical  supply  level,  and  its  own 
supply  demand  rate.  #The  initial  pipeline  operation  dispatches 
cargo  carriers  on  a  periodic  basis  so  that  a  cargo  carrier 
arrives  and  transfers  supplies  to  the  ISP  just  at  the  time  when 
the  ISP’s  supply  level  drops  to  the  emergency  supply  level. 
Thus,  under  the  initial  conditions,  user  demands  are  being  met, 
their  supply  levels  remain  at  their  maximum,  and  the  ISP  does  not 
have  to  draw  from  its  emergency  supplies.  This  pipeline 
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operation  continues  until  a  contingency  occurs,  where  a 
contingency  reflects  a  change  in  a  user  demand  rate.  At  this 
time,  the  pipeline  operation  is  modified  so  that  the  ISP  will  be 
capable  of  meeting  the  new  demand  once  the  new  pipeline  operation 
is  in  effect.  In  the  interim  period,  several  things  could  occur. 
If  the  contingency  is  an  increase  in  demand  then  the  ISP  may  have 
to  begin  drawing  from  its  emergency  supplies  at  some  time. 
During  this  interim  period,  cargo  carrier  arrivals  will  be  more 
frequent,  since  expected  shortfalls  will  have  to  be  recovered. 
If,  during  this  period,  the  ISP  has  to  to  draw  from  emergency 
supplies  and  cannot  satisfy  the  user's  demands  (i.e.,  its  supply 
level  would  reach  the  critical  supply  level  before  the  arrival  of 
the  next  cargo  carrier),  then  the  user  supply  level  rates  are 
decreased  in  a  way  that  takes  into  account  their  essentiality 
priority  numbers.  In  this  case,  user  supply  levels  will 
decrease,  and  one  or  more  may  drop  below  their  safety  levels.  If 
this  occurs,  the  affected  user's  essentiality  priority  will  be 
assumed  at  unity,  and  supply  rates  will  be  readjusted.  Also,  a 
user  supply  level  may  eventually  reach  the  critical  level,  and, 
in  that  case,  the  user  is  assumed  to  withdraw.  Because  the  ISP 
will  no  longer  have  to  supply  that  user,  it  can  increase  the 
supply  rates  of  the  remaining  users.  Also,  this  decrease  in 
total  demand  will  impose  a  requirement  to  modify  the  planned 
pipeline  operation,  which  has  not  yet  even  stabilized. 
Furthermore,  user  withdrawal  due  to  depletion  of  one  class  of 
supplies  will  also  affect  the  pipelines  that  serviced  that  user 
for  the  other  classes  of  supplies.  This  represents  the  only 
dependency  between  the  three  pipelines. 

The  pipeline  operation  continues  in  the  above  manner 
until  one  of  four  events  occurs:  an  input-specified  duration 

time  has  been  reached;  all  users  have  withdrawn;  an  ISP's  supply 
level  will  drop  below  its  critical  level  before  the  arrival  of 
the  next  cargo  carrier;  or  all  contingencies  have  been  processed, 
and  each  pipeline  operation  has  reached  stabilization. 
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The  output  of  the  module  consists  of  four  tables  for 
each  pipeline.  The  first  table  specifies  the  times  and  reasons 
for  the  occurrence  of  selected  events,  such  as  when  a  user  supply 
level  drops  below  its  safety  level,  a  user  withdraws,  a  cargo 

carrier  arrives  at  an  ISP,  and  so  on.  The  second  table  specifies 
the  supply  levels  of  the  ISP  and  the  users  at  the  time  of 

occurrence  of  an  event  and  at  predetermined  time  intervals.  The 
third  table  just  prints  out  the  supply  levels  at  the 
predetermined  time  intervals.  The  fourth  table  prints  out  the 
supply  rates  of  the  ISP  and  users  at  the  beginning  of  the 
operation  and  at  each  time  that  at  least  one  of  these  supply 

rates  changes  value.  This  latter  table  provides  the  required 

inputs  to  BALFRAM,  where  one  or  more  of  the  users  could  represent 
supply  nodes  within  a  BALFRAM  scenario. 

This  SUPPLY  DISTRIBUTION  MODULE  represents  an  initial 
construct  of  an  analytical  tool  designed  to  provide  a  basis  for 
evaluating  the  distribution  of  supplies  to  operational  forces 
engaged  in  a  theater  war  scenario  within  the  context  of  BALFRAM. 
The  module  design  was  constrained  by  the  level-of-ef fort 
limitations  of  this  research  contract.  However,  it  is  capable  of 
being  expanded  in  future  research  efforts  to  include  additional 
features,  such  as  the  following: 

e  Pipelines  servicing  more  than  one  ISP 

•  Movement  of  users  and  the  ISP  as  contingency  action 

•  Limited  capacity  pipelines  between  users  and  the  ISP 

•  Emergency  pipelines 

•  Cargo  ship  limited  availability  at  the  supply  source 

•  Concurrent  operation  with  the  main  BALFRAM. 

Expansion  of  the  module  to  include  these  features  would  enhance 
its  usefulness  as  an  analytical  tool  for  evaluating  the 
effectiveness  of  supply  operations  in  a  theater  war  scenario. 


II  BALFRAM 


A.  Overview 

1 .  General 

BALFRAM*  is  a  computer-based,  compiler-like  model  that 
can  be  tailored  to  diverse  geographies,  force  mixes,  strategies, 
tactics,  and  levels  of  aggregation.  BALFRAM  provides  an  abstract 
framework  within  which  problems  of  force  requirements  and 
capabilities  can  be  analyzed.  It  is  an  event-triggered, 
time-stepped  technique  for  modeling  the  engagement  of  opposing 
military  forces  and  estimating  the  expected  value  outcome  of  3uch 
engagements,  thus  assisting  in  the  evaluation  of  the 
effectiveness  of  alternative  force  levels,  mixes,  deployments, 
employments,  utilizations,  and  support  options.  BALFRAM  is  a 
two-sided  methodology  that  encompasses  Ground,  Air,  Naval  and 
Special  Purpose  Forces. 

2.  Scenario  Geography 

Scenario  geography  is  illustrative  of  the  model's 
abstraction.  Geography  is  represented  in  terms  of  nodal  points 
and  lines  of  access  between  nodes,  i.e.,  a  network.  The  nodal 
points  can  represent  worldwide,  broadly  defined  geographical 
areas  (battle  zones,  supply  areas)  or  individual  locations  such 
as  airbases,  ports,  or  key  military  objectives.  Areas 
represented  by  a  node  can  range  in  size  from  that  required  for  an 
Army  squad  to  that  required  for  a  naval  or  air  battle.  The  lines 
of  access  between  nodes  represent  the  paths  over  which  the  forces 
and  logistics  of  both  sides  must  move.  These  lines  and  nodes 
also  can  reflect  strategic  movement  options  such  as  port  or 
airhead  access  rights,  air  space  overflight  restrictions  or 
* 

See  References  1-H  appearing  at  the  end  of  the  main  body  of  this 
report  for  a  list  of  detailed  documentation  of  BALFRAM. 
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contested  sea  lanes.  In  addition,  these  lines  and  nodes  can 
reflect  tactical  factors  such  as  military  objectives,  roads  and 
critical  river  crossing,  and  environmental  conditions.  The  nodal 
network  can  be  as  detailed  or  general  as  required  for  the  problem 
under  consideration. 

3.  Force  Description 

Force  characteristics  within  BALFRAM  are  described  by 
the  numbers,  types,  locations,  and  status  of  units  that  each  side 
can  ultimately  commit  during  the  scenario.  Each  unit  is  a 
notional  concept.  Unit  size  can  vary  from  representing  a  company 
up  to  representing  theater  size  force.  Furthermore,  a  unit  can 
represent  any  of  a  variety  of  force  types.  For  instance,  a  unit 
can  represent  a  division  force  equivalent  or  several  divisions,  a 
formation  of  aircraft,  a  ship  or  a  large  naval  force.  Individual 
members  of  a  specific  unit  have  similar  characteristics  such  as 
combat  effectiveness,  attrition  capability,  sustainability,  and 
mobility.  Every  unit,  whether  it  be  enemy,  allied  nation,  or 
U.S.  main  battle  force,  has  at  least  the  following  attributes: 

1)  Unit  type  -  Ground,  Air,  Naval  or  Special 

2)  Unique  Unit  Identifier 

3)  Unit  Size 

4)  Index  of  Combat  Effectiveness  (ICE) 

5)  Time  at  which  unit  is  introduced  into  scenario 

6)  Mobility  factor  to  define  rate  of  movement 

7)  Initial  geographic  location  for  unit 

8)  Geographic  location  of  unit's  initial  objective. 

4.  Contingency  Logic 

As  mentioned  above,  the  initial  deployment  of  all 
available  units  and  their  initial  goals  are  specified  as  part  of 
the  force  characteristics.  In  addition  to  the  manner  in  which 
available  forces  are  planned  to  be  employed,  it  is  sometimes 
necessary  or  desirable  to  alter  deployment  policies  or  mission 
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allocations  contingent  upon  some  set  of  possible  circumstances 
which  could  occur.  These  contingent  activities  provide  a  model 
of  the  operational  priorities  and  movement  logic  that  must  govern 
individual  combat  units  as  the  scenario  progresses.  BALFRAM, 
rather  than  imposing  a  fixed  set  of  limited  contingency  rules, 
allows  the  user  to  specify  any  unique  set  of  rules  for  the 
particular  problem  and  scenario  under  study.  This  method  puts 
the  responsibility  for  creative  decisionmaking  logic  on  the  user 
analyst  (where,  for  maximum  flexibility,  it  should  rest). 

Contingent  activities  may  be  specified  in  many 
different  ways.  The  logic  statements  that  effect  these  changes 
are  of  the  general  form:  if  some  condition  is  true,  then  perform 
an  action  for  specified  units.  The  "condition"  portion  of  the 
statement  may  be  the  location  of  a  friendly  or  enemy  unit,  the 
combat  effectiveness  of  a  unit,  the  attrition  suffered  by  either, 
the  arrival  or  departure  of  units  at  a  node,  or  the  passage  of 
time.  The  action  portion  of  the  statement  can  relate  to  force 
movements,  a  specific  unit's  mission  reallocation,  or  even  a 
change  in  the  characteristics  of  the  forces  involved. 
Contingency  logic  within  BALFRAM  provides  an  extremely  powerful 
means  of  structuring  scenarios  and  game  progression  around  a  wide 
variety  of  analytical  rules. 


5.  Engagement  Simulation 

The  fight  laws  used  in  BALFRAM  are  an  adaption  of  the 
Lanchester  Laws  of  Combat.  These  laws  define  the  attrition  to 
each  side  in  an  engagement  as  a  function  of  time.  They  also 
permit  determination  of  the  time  needed  for  one  side  to  defeat 
the  other.  However,  BALFRAM  is  not  a  Lanchester  model  per  se; 
rather,  it  is  a  modularized  imulation  that  uses  the  Lanchester 
laws  for  some  attrition  calculations.  If  the  user  prefers  other 
than  the  Lanchester  laws  for  a  given  engagement,  either  the 
exogenous  fire  routines,  or  a  user-developed  algorithm  may  be 
specified. 

BALFRAM  contain  two  basic  differential  fight  laws:  the 
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square  law  and  the  linear  law.  The  differential  fight  laws 
embody  the  assumption  that  two  forces,  each  capable  of  inflicting 
attrition  on  the  other,  are  engaged  in  battle.  In  addition,  they 
assume  that,  although  unit  casualty-inflicting  power  may  differ, 
it  is  known  for  all  units  of  both  forces.  Finally,  they  assume 
that  all  opposing  units  engaged  in  a  battle  are  within  firing 
range  of  each  other.  In  addition  to  the  shared  assumptions,  the 
square  law  assumes  that  each  unit  knows  the  location  of  opposing 
units  and  can  determine  the  results  of  its  own  fire;  hence,  it 
directs  its  fire  only  at  surviving  enemy  units.  The  additional 
linear  law  assumptions,  in  contrast,  are  that  each  unit  knows 
only  the  general  area  in  which  opposing  units  are  located  and 
cannot  determine  the  results  of  its  fire;  hence,  it  distributes 
it  fire  uniformly  over  the  enemy-occupied  area.  A  mixed  law 
situation,  in  which  the  linear  law  assumptions  apply  to  one  force 
and  the  square  law  assumptions  to  the  other,  is  also  possible. 

The  BALFRAM  software  permits  the  user  to  select  the 
fight  law  that  is  applicable  to  each  node  at  which  a  battle  may 

occur.  Selection  should  be  made  on  the  basis  of  how  well  the 

various  fight  law  assumptions  are  satisfied  and/or  on  the  basis 
of  empirical  evidence  of  applicability. 

6.  Logistics  Simulation 

Logistics  modeling  in  BALFRAM  is  accomplished  by 
establishing  a  set  of  "pipelines"  along  which  supplies  flow  to 
designated  units.  A  pipeline  may  connect  many  nodes  and  supply  a 
large  number  of  units.  As  a  result  of  enemy  interdiction, 
pipeline  capacity  may  be  reduced.  The  effectiveness  of  the 

pipeline-supplied  units  is  then  reduced  in  proportion  to  the 

shortfall  of  supplies.  Provision  is  made  for  pipeline 
regeneration  rates,  deployment  factors,  resupply  rate  factors, 
and  designation  of  nodes  and  units  to  be  resupplied.  Logistic 
pipelines  can  represent  air,  sea,  or  land  supply  lines  and  thus 
accomodate  strategic  heavy  airlift,  cargo  ships,  or  truck 
convoys.  The  analyst  may  generate  pipelines  for  both  friendly 
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ana  enemy  forces  ana  specify  which  of  each  siae's  unit3  are  to  be 
employed  in  pipeline  interdiction  roles.  Logistics  simulation  is 
discussed  in  more  detail  in  Section  C,  Model  Logistics. 

7.  Reports 

Any  model's  output  should  be  structured  to  allow  the 
analyst  to  examine  results  at  any  selected  level  of  detail. 
BALFRAM  has  a  number  of  features  to  select  meaningful  output, 
including  options  for  interdiction  history,  battle  node 
information,  and  summaries.  Also  available  is  a  complete 
description  of  the  input  scenario:  force  structure,  deployment, 
time-phased  military  objectives,  operational  and  support 
concepts,  and  scheduling. 

8.  User  Controls 

Integral  to  the  BALFRAM-based  contingency  force 
methodology  is  a  set  of  sensitivity  analysis  controls  to 
automatically  vary  key  scenario  parameters  and  iterate  the  game. 
User-specified  multipliers  to  order  of  battle,  indices  of  combat 
effectiveness,  exogenous  firepower,  or  even  deployment  time  will 
produce  automatic  sensitivity  iterations.  Similarly,  the 
distribution  of  forces  can  be  varied  by  automatically  allocating 
progressively  larger  percentages  of  forces  from  one  group  of 
units  to  another  geographically  separate  group.  This  process 
generates  an  output  matrix  of  scenario  results.  Another  BALFRAM 
method  for  automatically  generating  sensitivity  results  is  to 
randomize  certain  input  parameters  around  given  input  values  so 
that  a  normal  distribution  of  each  input  parameter  is  produced. 
Scenario  results  for  each  input  value  or  set  of  randomized  input 
values  are  generated  so  that  the  output  set  can  be  examined  for 
it3  distribution.  This  technique  may  be  used,  for  example,  to 
determine  a  distribution  of  force  level  input  values  that  will 
result  in  a  U3er-specified  scenario  outcome.  As  this  example 
shows,  scenario  outcomes  can  be  stipulated  before  the  game. 
Outcomes  are  defined  in  terms  of  the  difference  between  the 
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surviving  components  of  the  BLUE  and  RED  units  of  interest; 
BALFRAM  then  performs  iterative  solutions  based  on  varying 
initial  force  levels  to  converge  on  the  correct  force  size  to 
produce  the  stipulated  outcome.  Based  on  the  assessment  of  the 
effectiveness  of  combat,  combat  support,  or  service  support 
forces'  contribution  to  the  stipulated  outcome,  force  structuring 
and  scheduling  can  be  determined  for  any  desired  outcome. 
Further,  an  estimate  can  be  established  of  the  extent  of  required 
host  nation  support  and/or  cross-service  support.  This  estimate 
would  be  an  outgrowth  of  shortfalls  in  organic  force  logistic 
capability.  This  integral  set  of  sensitivity  analysis  controls 
indicates  to  the  analyst  the  contribution  of  the  force  components 
to  meeting  the  time-phased  military  objectives.  Also,  the 
analyst  receives  indications  of  critical  constraints,  paths,  and 
deficiencies  in  the  concept  of  operations  and  candidate  force 
structure. 


B.  Model  Structure  and  Requirements 

1 .  Hardware  Characteristics 

BALFRAM  is  a  self-contained  set  of  subroutines  that  do 
not  support  or  maintain  any  external  data  base  or  system.  The 
BALFRAM  software  has  been  programmed  in  FORTRAN  IV  and  has  run  on 
the  Honeywell  6060  computer,  the  Control  Data  6000,  and  the  IBM 
4341.  It  consists  of  over  10,000  FORTRAN  statements,  including 
approximately  50  subroutines.  Run  times  vary  from  minutes  to 
hours  of  CPU  time,  depending  on  the  number  of  units  involved  and 
the  scenario  complexity. 

2.  Software  Architecture 

The  basic  program  is  a  high  level  analytical 
bookkeeping  device  that,  when  provided  with  input  values  to 
describe  force  characteristics  and  operational  logic,  will  move 
forces  over  the  defined  geography  of  the  scenario.  The  program 
will  permit  the  forces  to  engage,  when  appropriate,  and  will 


estimate  the  outcome  of  these  engagements  according  to  attrition 
computations  that  have  been  mathematically  defined.  The  software 
has  been  designed  with  a  wide  spectrum  of  military  applications 
in  mind;  as  a  result,  individual  problems  to  be  modeled  do  not 
always  require  that  the  full  capabilities  of  the  system  be 
exercised.  To  use  BALFRAM,  a  projected  real  world  scenario  must 
be  translated  into  a  BALFRAM  scenario.  This  is  done  by 
abstracting  the  geography  of  the  real  world  scenario  into  nodes 
representing  geographic  locations  at  which  activity  may  take 
place  and  by  describing  planned  and  contingent  activity  through 
the  use  of  BALFRAM  descriptors  (inputs).  Thus,  BALFRAM  is  not  a 
"model"  until  a  set  of  descriptors  has  been  assembled  to  compose 
a  scenario. 

As  indicated  previously,  BALFRAM  is  written  in  FORTRAN 
IV.  The  number  of  each  type  of  descriptor  is  limited  by 
DIMENSION  sizes  in  the  program.  Thus,  the  maximum  problem  size 
depends  on  the  memory  size  of  the  host  computer  and  whether  thi3 
size  is  fixed,  such  as  in  partitions  or  a  virtual  memory. 
BALFRAM  also  creates  intermediate  disk  files  that  must  be 
accomodated . 

The  BALFRAM  documentation  contains  block  diagrams  of 
overall  logic,  flow  charts  for  all  BALFRAM  subroutines,  the 
subroutine  calling  structures,  definition  of  the  contents  of 
files  and  common  block  arrays,  and  error  messages. 


C.  Model  Logistics 

A  LGINTDIC  (logistic  interdiction)  card  set  is  used  to 
describe  each  logistic  pipeline  of  the  BALFRAM  scenario  and  to 
include  the  effects  of  reduction  of  pipeline  capacity  as  a  result 
of  interdiction.  Provision  is  made  for  pipeline  regeneration 
rates,  deployment  factors,  resupply  rate  factors,  and  designation 
of  nodes  to  be  resupplied.  Each  logistic  pipeline  can  be 
represented  by  specifying  a  (pipeline)  node,  a  ground,  air,  or 
naval  unit  (termed  a  pipeline  unit),  and  a  ground,  air,  or  naval 
reserve  unit  (termed  a  pipeline  reserve  unit).  The  node  contains 


the  pipeline  unit,  and  interdiction  can  only  occur  there.  As 
this  unit  is  attrited,  components  are  instantaneously  transferred 
to  it  from  the  pipeline  reserve  unit.  Pipeline  regeneration  is 
simulated  by  increasing  the  components  of  the  pipeline  reserve 
unit  at  a  user  specified  time  varying  (regeneration)  rate.  For 
example,  if  destroyed  cargo  ships  can  be  replaced  at  the  rate  of 
half  a  ship  per  day,  starting  30  days  after  scenario 
commencement,  the  regeneration  rate  would  be  0.0  from  0  to  30 
days  and  then  0.5. 

Throughput  capacity  (or  supply  delivery  rate)  of  each 
pipeline  unit  component  is  equal  and  specified  in  units  of  weight 
(usually  tons)  per  unit  of  time.  The  nodes  to  be  supplied  by 
each  pipeline  are  specified,  as  are  the  units  that  will  be 
replenished  or  provisioned  for  deployment.  Each  unit  to  be 
resupplied  must  be  given  a  resupply  factor  indicating  the 
quantity  of  supplies  required,  per  unit  time  per  component,  to 
prevent  unit  firepower  from  being  degraded  by  logistic  shortfall. 
Similarly,  each  unit  to  be  provisioned  for  deployment  can  be 
provided  with  a  deployment  factor.  This  factor  specifies  the 
supplies  required  by  each  component  of  each  specified  unit  before 
that  unit  can  be  deployed.  If  the  pipeline  is  unable  to  convey 
sufficient  supplies  to  the  unit  by  its  scheduled  time  of 
deployment,  deployment  is  delayed  until  the  required  quantity  of 
supplies  is  provided. 

Pipeline  throughput  capacity  is  a  function  of  interdiction, 
regeneration  rate,  and  the  number  of  components  in  the  pipeline 
unit  and  reserve.  When  pipeline  throughput  capacity  is 
inadequate  to  satisfy  the  needs  of  the  supplied  units,  unit 
firepower  effectiveness  is  degraded  by  an  operability  factor 
varying  directly  with  the  shortfall  of  supply  delivery  rate. 
This  operability  factor  is  determined  as  follows: 

OF  =  minj^p.  l}  (I'i-1) 
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where  PTC  is  the  pipeline  throughput  capacity  and  QS  is  the 
quantity  of  supplies  required  per  unit  time  by  all  units  being 
supplied . 

D.  Description  of  Model  Attrition 

The  degradation  of  unit  firepower  effectiveness  due  to 
logistic  shortfalls  is  modeled  within  the  fight  laws  for 
homogeneous  forces  in  BALFRAM.  Suppose  that  at  node  n,  there  are 
two  units  in  combat  and  exogenous  firepower  is  contributed  by  one 
unit  on  each  side.  Let  FS(t)  and  ES(t)  represent  the  number  of 
surviving  components  of  the  friendly  and  enemy  units, 
respectively,  at  time  t.  The  square  fight  law  of  enemy  attrition 
is  given  by 


•d^-S-(-t-I  =  -FA*  FS (t)  -  FEF 
at 


(11-2) 


and  the  linear  fight  law  of  enemy  attrition  is  given  by 


=  _FA  ,  Es(t)  •  FS (t)  -  FEF  (II-3) 

where  FA  is  the  friendly  attrition  coefficient  and  FEF  is  the 
friendly  exogenous  firepower  parameter.  These  parameters  are 
composed  of  multiplicative  factors  as  indicated  in  Eq.  (4)  and 
(5)  below: 


FA  =  FFB  *  FOF  *  FICE 


(II-4) 
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where  FFB  is  the  friendly  force  base  attrition  factor.  FOF  is 
the  friendly  unit  operability  factor  due  to  logistic  shortfall 
(as  given  by  Eq.  ( 1 1— 1 )  for  friendly  units),  and  FICE  is  the 
friendly  unit  index  of  combat  effectiveness; 

FEF  =  EFE  •  CP •  FOF  (II-5) 


where  EFE  is  the  exogenous  firepower  effectiveness  coefficient, 
and  CP  is  a  constant  of  proportionality  that  depends  on  the 
method  of  computation  used  to  compute  EFE.  This  method  of 
computation  is  determined  by  a  user-set  code.  The  model  permits 
EFE  to  be  any  of  the  following: 

•  A  constant. 

•  Directly  proportional  to  the  friendly  order  of 

battle  at  a  specified  node. 

•  Directly  proportional  to  the  order  of  battle  of  a 
specified  friendly  unit. 

•  Directly  proportional  to  the  friendly  order  of 

battle  at  a  specified  node. 

•  Directly  proportional  to  the  friendly  order  of 

battle  at  a  specified  node  and  to  the  enemy  order 
of  battle  at  a  specified  node.  The  two  nodes  are 
usually  different,  but  need  not  be. 

•  Directly  proportional  to  the  friendly  order  of 

battle  at  a  specified  node  and  the  order  of  battle 
of  a  specified  enemy  unit. 

•  Directly  proportional  to  the  friendly  order  of 

battle  at  a  specified  node  and  to  the  enemy  order 
of  battle  at  the  node  previously  specified  and  at 
some  other  specified  node. 

•  Directly  proportional  to  the  friendly  orders  of 
battle  at  two  specified  nodes  and  the  enemy  order 
of  battle  at  a  specified  node. 

•  Directly  proportional  to  the  order  of  battle  of  a 
specified  friendly  unit,  the  friendly  order  of 
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battle  at  a  specified  node,  and  the  enemy  order  of 
battle  at  a  specified  node. 


•  Directly  proportional  to  the  friendly  order  of 

battle  at  a  specified  node  and  the  enemy  orders  of 
battle  at  two  specified  nodes. 

•  Directly  proportional  to  the  friendly  order  of 

battle  at  a  specified  node,  the  enemy  order  of 
battle  at  a  specified  node,  and  the  order  of  battle 
of  a  specified  enemy  unit. 

•  Directly  proportional  to  the  friendly  orders  of 
battle  at  two  specified  nodes. 

•  Directly  proportional  to  the  friendly  order  of 

battle  at  a  specified  node  and  the  order  of  battle 
of  a  specified  friendly  unit. 

The  dimensions  of  EFE  and  CP  depend  on  the  computation  method 
specified  for  EFE.  Dimensions  of  exogenous  firepower 
effectiveness  coefficients  are  discussed  in  detail  in  BALFRAM 
User  Manual,  Appendix  D,  "Computation  of  Exogenous  Firepower 
Effectiveness." 

For  the  general  case,  where  there  are  several  units  on  each 
side  at  a  given  node,  the  computations  of  enemy  attrition  follow 
the  same  above  pattern.  However,  the  representations  of  the 
coefficients  and  parameters  are  much  more  complicated.  In 
addition,  the  fight  laws  of  friendly  attrition  parallel  those  of 
enemy  attrition. 

E.  Summary 

In  summary,  BALFRAM  provides  a  unified  or  balanced  approach 
to  force  analysis  by  integrating  the  simultaneous  activities  of 
land,  sea,  and  air  forces.  It  can  be  used  to  follow  and  assess 
interactions  between  the  component  services  in  their  coordinated 
support  of  a  military  objective.  The  model  also  includes 
optional  provisions  for  statistical  sensitivity  analyses  to 
quantify  the  relationship  between  model  input  and  model  output. 
BALFRAM  is  constructed  so  that  the  user  defines  the  problem  or 
scenario  of  interest  from  an  operational  standpoint  and 
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translates  it  into  BALFRAM  terms.  The  user  also  provides  the 
operational  logic  (strategy  and  tactics)  that  will  be  applied  to 
the  situation  and  translates  this  logic  into  BALFRAM  terms.  The 
translations  are  done  through  specific  user  inputs  that  assemble 
the  appropriate  components  of  the  BALFRAM  program.  Using  the 
BALFRAM  software  as  a  tool,  the  user  constructs,  with  output 
feedback,  a  notional  model  that  embodies  his  abstraction  of  the 
real  world  process.  Even  after  the  initial  model  construct  has 
been  completed,  modifications  can  be  effected  as  insights  into  a 
particular  problem  are  obtained.  Subsequent  sensitivity  analyses 
and  tradeoffs  can  be  made.  This  iterative  feedback  process 
enables  the  user  to  construct  a  BALFRAM-based  model  that  has 
analytical  relevance  to  military  contingency  planning  problems  as 
the  user  perceives  them. 
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Ill  IMPROVED  BALFRAM  LOGISTICS 

A.  Logistics  Representation  in  BALFRAM 

The  purpose  of  the  logistics  feature  of  BALFRAM  is  to  impair 
unit  effectiveness  when  logistical  capacity  will  not  sustain 
maximum  effectiveness.  The  main  components  of  the  logistics 
simulation  are  the  logistical  transportation  units  assembled  into 
pipeline  units  and  their  associated  reserve  units.  These  units 
have  an  order  of  battle  measured  in  units  of  transportation 
capacity,  such  as  convoys,  cargo  ships,  containers,  reefers  and 
the  like.  Each  unit  of  transportation  has  a  supply  capacity  such 
as  tons  per  convoy  or  cargo  ship.  The  fighting  units  have  a 
supply  requirement  that  is  specified  in  supplies  per  fighting 
unit.  All  of  these  rates  are  actually  expressed  in  BALFRAM  as 
rates  per  time  unit  (i.e.,  tons  per  day  or  tons  per  truck  per 
day) . 

The  logistics  pipeline  is  assumed  to  begin  at  a  supply  node 
(port  or  major  supply  depot)  and  extend  to  the  supplied  units. 
Attrition  in  the  logistics  simulation  is  assumed  to  affect  only 
the  transportation  units  in  the  pipeline,  not  the  reserve  units 
or  the  supply  node.  Supplies  are  always  available  if 
transportation  capacity  is  available  to  move  them.  BALFRAM  deals 
with  transporting  supplies,  not  with  acquiring  and  stockpiling. 

Resupply  of  transportation  units  occurs  at  a  prespecified 
rate  and  begins  at  a  scheduled  time.  When  there  are  more 
transportation  units  available  than  are  required  by  the  pipeline 
to  supply  the  combat  units,  the  excess  are  held  in  the  reserve 
unit  until  needed.  Thus,  the  reserve  units  build  and  hold  any 
surpluses  that  are  protected  from  attrition. 

Each  logistics  pipeline  is  assigned  a  pipeline  unit,  a 
reserve  unit,  and  a  specified  set  of  combat  units  and  nodes  to 
supply.  Each  logistics  pipeline  in  BALFRAM  is  independent  of  all 
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other  pipelines.  The  supply  requirements  are  computed  for  all 
assigned  combat  units  when  they  are  at  the  specified  nodes.  This 
is  done  by  multiplying  the  unit  size  by  the  required  supply  rate. 
The  sum  of  these  requirements  is  compared  with  the  supplies 
available  (i.e.,  number  of  transportation  units  available 
multiplied  by  the  supply  capacity  per  unit).  The  number  of 
transportation  units  available  is  the  sum  of  the  units  in  the 
pipeline  and  reserve  units. 

When  the  available  supplies  are  fewer  than  the  required 
supplies,  the  combat  effectiveness  of  each  supplied  unit  is 
scaled  down  to  an  appropriate  level.  The  current  scaling  method 
in  BALFRAM  consists  of  multiplying  each  combat  unit's  firepower 
potential  by  the  proportion  of  required  supplies  that  are 
available.  This  proportion  is  limited  to  values  between  0.001 
and  1.0. 

Another  feature  of  the  logistics  simulation  is  to  control 
combat  unit  deployment  as  a  function  of  the  availability  of 
logistics.  Deployment  of  any  combat  unit  can  be  delayed  until 
there  is  enough  transportation  capacity  to  accomodate  the  units 
already  deployed,  leaving  enough  capacity  to  also  supply  any  unit 
about  to  be  deployed.  Unit3  already  deployed  have  first  priority 
on  any  supplies.  The  rate  required  for  deployment  can  be 
specified  as  different  from  the  regular  combat  support  rate  to 
accomodate  predeployment  stockpiling.  When  there  is  a  conflict 
between  a  unit  reaching  its  deployment  time  and  a  unit  that  has 
held  up  deployment  for  lack  of  supplies,  the  latter  unit  will  be 
deployed  first. 

B.  Shortcomings  of  Logistics  Simulation 

There  is  general  acknowledgement  that  lack  of  logistics 
support  will  decrease  combat  unit  effectiveness.  However,  there 
is  not  agreement  on  the  quantitative  effects  on  combat  unit 
potential  that  would  result  from  logistic  support  inadequacies  of 
various  types,  such  as  supply  shortfalls  or  maintenance  system 
deficiencies.  This  was  considered  in  the  development  of  the 
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logistics  simulation  within  BALFRAM.  It  was  felt  that  a 
generalized  logistic  effects  model  with  flexibility  of  parameter 
selection  was  better  than  ignoring  logistic  effects  altogether. 
At  least,  the  sensitivity  of  outcomes  under  variations  of 
logistics  could  be  examined,  even  if  absolute  outcomes  could  not 
be  estimated.  In  an  aggregated  model  such  as  BALFRAM,  this 
strategy  appeared  reasonable,  but  there  are  some  areas  where 
potential  improvements  can  be  made. 

Logistics  is  not  a  monolithic  system  delivering  equal 
quantities  of  equally  needed  supplies.  The  logistics  system 
delivers  separate  items  for  a  multitude  of  purposes.  These  items 
are  generally  grouped  into  classes  for  ease  of  management  and 
handling,  such  as  bulk  POL,  ammunition,  and  other  supplies. 

The  effects  of  shortfalls  in  these  classes  on  combat 
potential  are  markedly  different,  depending  on  both  the  class  and 
the  type  of  unit  being  supplied.  The  predecessor  BALFRAM  version 
treats  all  supplies  as  indistinguishable  and,  therefore,  of  equal 
effect  on  the  success  of  a  combat  unit.  As  a  first  order 
approximation  in  an  aggregated  model,  this  provides  the  ability 
to  examine  logistics  effects. 

The  relation  between  the  shortfall  of  supplies  and  the 
change  in  combat  effectiveness  of  a  supplied  unit  is  another  area 
of  conjecture.  A  10%  shortage  of  ammunition  may  reduce  unit 
effectiveness  by  20%  by  causing  the  inability  to  fire  and 
maneuver.  However,  a  10%  shortage  in  personal  supplies  may  only 
cause  a  2%  reduction  in  unit  effectiveness  as  existing  supplies 
are  used  beyond  the  normal  point  of  retirement.  This  difference 
in  effect  would  argue  against  a  single  class  of  supplies,  while 
it  would  argue  for  separate  transfer  functions  relating  shortfall 
in  supplies  to  reduction  in  combat  effectiveness.  These 
functions  should  be  described  parametrically  and  be  selectable 
for  user  sensitivity  studies. 

The  existing  BALFRAM  logistic  mode  does  not  stockpile 
supplies,  but  it  does  stockpile  the  means  for  delivering  the 
supplies.  The  logistics  depots  are  assumed  to  always  have 
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adequate  supplies,  and  the  constraint  is  on  the  delivery  means. 
Actual  logistic  systems  are  sensitive  to  both  factors.  Shortages 
in  either  factor  choke  the  supplies  to  the  combat  units  and 
affect  combat  capability. 

The  current  logistics  simulation  assumes  that  the  supplies 
are  instantaneously  delivered  (within  the  program  time  unit)  to 
the  combat  units.  Only  the  capacity  constraints  are  checked  for 
validity.  Thus,  when  unit  size  or  supply  requirement  rates 
change,  there  is  not  the  lag  time  that  there  would  be  in  an 
actual  supply  system.  This  simplification  reduces  the  complexity 
of  the  programming  logic.  Users  must  be  aware  that  the  exact 
physical  flow  of  supplies  is  not  simulated  in  BALFRAM. 

C.  Logistics  Improvements  to  BALFRAM 

One  major  improvement  for  BALFRAM  is  the  addition  of 
multiple  supply  classes.  Instead  of  a  single  supply  stream, 
BALFRAM  has  been  modified  to  use  three  supply  classes  to 
determine  the  combat  effectiveness  of  a  specified  unit.  For 
example,  the  three  classes  could  represent  bulk  POL,  ammunition, 
and  other  supplies.  Each  of  the  classes  has  independent 
transportation  capacity,  regeneration  capability,  and  attrition. 
Supply  shortfalls  in  the  three  classes  each  generate  independent 
operability  factors  that  are  combined  to  compute  the  total  loss 
of  combat  effectiveness  of  the  unit. 

An  operability  factor  is  computed  for  each  supply  class  for 
each  unit  supported  by  the  pipeline.  Pipelines  are  defined  by 
the  collection  of  units  that  are  supplied  and  the  nodes  where 
those  units  must  be  located  to  receive  those  supplies.  The 
operability  factor  is  computed  from  a  transfer  function  that  uses 
the  ratio  of  supplies  available  to  supplies  required. 

Individual  supply  class  shortfalls  are  used  to  compute 
operability  factors.  Let  i  generically  denote  a  supply  class  and 
denote  the  ratio  of  supplies  available  to  supplies  required 
for  the  ith  supply  class  relative  to  a  particular  combat  unit, 
then  the  operability  factor  for  that  unit  can  be  represented  as 
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follows 


OF.  =  f. (R, )  (III-1) 

1  11 

where  f  denotes  the  particular  effectiveness  operability 
transfer  function  used  for  supply  class  i  (the  types  of  transfer 
functions  now  allowable  in  BALFRAM  are  described  later  on  in  this 
section).  For  a  given  combat  unit,  these  factors  must  be 
combined  to  produce  a  single  effect  on  the  unit's  combat 
potential.  The  operability  factors  for  each  class  of  supplies 
are  multiplied  together  to  compute  a  unit  operability  factor  (OF) 
that  is  to  be  used  to  reduce  the  unit's  combat  potential.  Thus, 


OF  =  f1(R1)*f2(R2).f3(R3)  (IH-2) 

The  manner  by  which  the  operability  factor  is  u3ed  in  the 
attrition  equations  of  BALFRAM  is  described  in  Section  D  of 
Chapter  II. 

A  second  change  in  the  BALFRAM  logistics  module  allows  more 
flexibility  in  the  selection  of  the  transfer  function  that 
computes  the  operability  factor  from  the  ratio  of  supplies 
available  to  supplies  required  for  each  supply  class.  This 
computation  has  been  changed  to  a  parametric  form  where  the  user 
can  select  multiple  transfer  function  forms.  This  way,  the  user 
is  not  restricted  to  a  linear  transfer  function.  In  addition  to 
choosing  the  basic  function,  the  user  also  provides  equation 
coefficients  that  give  a  specific  shape  to  the  basic  function. 
The  three  basic  equational  forms  currently  implemented  are  as 
follows,  where  R  is  the  ratio  of  supplies  available  to  supplies 
required,  OF  is  the  supply  operability  factor  of  the  combat  unit, 
and  a  and  b  are  user-specified  function  parameters: 
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Polynomial  Form 


r 


OF  =  Rb  ( III— 3) 

•  S-Curve  Form 


(III-4) 


•  Exponential  Form 


OF 


1-e 


a 


( III-5) 


Examples  of  the  shapes  of  these  transfer  functions  are  presented 
in  Figures  III-1  to  III-3,  respectively.  Note  that,  in  each 
case,  the  operability  factor  is  zero  when  R  is  zero  and  unity 
when  R  is  unity.  The  previous  linear  transfer  function  is  the 
degenerate  case  of  the  polynomial  form  with  b  equal  to  1. 

D.  Implementation  Strategy 

BALFRAM  is  a  large,  complex  FORTRAN  program.  Because  it  was 
not  implemented  on  a  virtual  storage  computer,  the  program  mu3t 
be  divided  into  overlays  or  executable  modules  that  will  fit 
within  memory  limits.  BALFRAM  implements  the  individual 
descriptor  cards  in  a  modular  fashion  through  individual 
subroutines.  Data  communication  is  through  COMMON  statements  and 
intermediate  disk  files  for  storing  model  status  after 
initialization.  The  disk  files  permit  running  iterations  without 
reinitializing  the  model. 

Any  logic  changes  must  fit  within  the  existing  structure  of 


Logistics  Degradation  Factor  (OF) 


b 

Equation:  OF  «  R 


Figure  III-l.  POLYNOMIAL  LOGISTICS  TRANSFER  FUNCTION 
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if  R  <  a 


if  Ri  a 


Figure  III-2.  S-CURVE  LOGISTICS  TRANSFER  FUNCTION 
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Log! 


Figure  III-3.  EXPONENTIAL  LOGISTICS  TRANSFER  FUNCTION 


BALFRAM  if  changes  are  to  be  made  economically.  Changing  the 
program  structure  substantially  would  increase  the  cost  of 
program  maintenance  and  future  updates  by  requiring  large  amounts 
of  new  documentation.  Other  organizations  still  use  BALFRAM,  and 
it  is  desirable  that  changes  be  compatible  with  the  existing 
BALFRAM  input  so  that  existing  data  bases  can  be  run  with  any  new 
program  versions. 

These  factors  imply  that  any  changes  should  not  increase 
data  storage  or  change  input  formats,  if  possible.  New  features 
should  use  the  same  input  formats  and  substitute  new  data  for  old 
wherever  possible.  Such  changes  can  eliminate  the  need  for 
changing  the  input  module  and  its  associated  COMMONS.  Changes 
are  made  in  the  subroutines  that  implement  the  descriptor  logic 
by  reinterpreting  the  definition  of  the  existing  data  and  adding 
new  subroutine  logic  to  perform  the  new  functions. 

Using  this  conservative  approach  for  the  logistic  changes 
described  above  resulted  in  loss  of  one  previous  feature  and 
rearrangement  of  data  on  the  LGINTDIC  cards.  To  have  the  needed 
data  elements  to  describe  the  characteristics  of  the  three 
pipelines,  one  feature  was  eliminated.  That  was  the  ability  to 
change  the  regeneration  rate  of  the  transportation  capability  as 
a  function  of  time.  In  the  single  class  case,  this  feature 
permitted  specification  of  three  times  and  the  regeneration  rates 
that  would  be  effective  as  of  the  associated  time.  In  this  way, 
the  regeneration  rates  could  reflect  changes  in  supply 
capabilities  at  three  times  during  the  scenario. 

However,  it  is  possible  to  achieve  the  effect  of  increasing 
the  number  of  transportation  elements  in  the  pipeline  and  reserve 
units  with  the  new  three-class  logistics.  The  Parameter  Change 
(PARMCHNG)  card  permits  changing  any  of  several  unit  parameters 
at  a  specific  time  during  scenario  execution.  One  of  the 
parameters  that  may  be  changed  is  the  order  of  battle  (size  of  a 
given  unit).  The  PARMCHNG  card  can  increment  (or  decrement)  the 
unit  size.  Thus,  while  the  regeneration  rate  itself  cannot  now 
be  changed,  the  size  of  the  unit  could  be  incrementally  changed 
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at  regular  intervals  to  reflect  a  change  in  rate.  Although  more 
cumbersome,  this  process  still  allows  changing  the  transportation 
capacity  of  the  pipeline  and  reserve  units  of  each  class 
independently. 

The  new  data  necessary  to  desribe  the  three-class  situation 
is  obtained  by  reinterpreting  the  existing  data  on  the  four  types 
of  Logistic  Interdiction  (LGINTDIC)  cards  and  requiring  a 
specific  arrangement  of  the  Unit  Specification  (UNITSPEC)  cards 
for  the  pipeline  and  reserve  units.  The  major  change  in  the 
LGINTDIC  card3  is  to  substitute  the  transportation  capacity  and 
regeneration  rates  of  the  three  logistic  classes  for  the  previous 
specification  of  regeneration  rate  and  effective  time  data  on  the 
LGINTDIC  Card  3.  Minor  changes  also  occur  on  the  LGINTDIC  Card 
1. 

The  UNITSPEC  cards  for  the  three  pipeline  and  reserve  units 
are  now  required  to  be  in  consecutive  order  in  the  input  where, 
before,  logistic  UNITSPEC  cards  had  no  constraints  as  to  deck 
order.  Several  variables  on  the  UNITSPEC  card  for  the  reserve 
unit  are  now  reinterpreted  to  provide  parameter  data  for  the  new 
transfer  function  formulations. 


IV  SUPPLY  DISTRIBUTION  MODULE 


A.  General 

A  SUPPLY  DISTRIBUTION  MODULE  was  developed  as  a  separate 
adjunct  to  BALFRAM.  This  module  addresses  the  problem  of 
transporting  supplies  to  a  theater  area.  BALFRAM  can  first  be 
used  to  establish  the  requirements  imposed  on  the  pipelines 
providing  supplies  to  the  theater  area.  The  SUPPLY  DISTRIBUTION 
MODULE  can  then  be  used  to  determine  the  pipeline  characteristics 
necessary  to  meet  these  requirements. 

The  SUPPLY  DISTRIBUTION  MODULE  is  a  computer  program, 
designated  by  the  acronym  PIPLIN,  developed  under  this  study 
effort.  This  program  considers  a  set  of  three  quasi-independent 
supply  pipelines,  each  pipeline  representing  the  flow  of  one  of 
three  classes  of  supplies  (bulk  POL,  ammunition,  or  other 
supplies)  from  a  supply  source  or  depot  to  a  remote  intermediate 
supply  point  (ISP)  that  services  a  set  of  user  elements.  An  ISP 
could  represent  a  foreign  port,  a  remotely  located  supply  base,  a 
seaborne  mobile  logistic  force,  one  or  more  AOEs  in  company  with 
a  task  group,  or  simply  an  unattended  task  group  taken  as  a 
whole.  The  user  elements  could  represent  foreign-based  troops 
drawing  supplies  from  a  foreign  port  or  supply  base,  a  debarked 
marine  force  drawing  supplies  from  a  sea-based  logistic  support 
group,  or  a  task  group  drawing  supplies  from  underway 
replenishment  ships. 

Users  are  continuously  supplied  by  their  ISP,  while  the  ISP 
is  resupplied  on  a  periodic  basis  by  cargo  carriers  (ships  or 
aircraft)  whose  cycle  time  includes  transit  time,  loading  and 
unloading  times,  preparation  time,  and  a  delay  time  for  routine 
maintenance  and  other  activity  between  cruises  or  flights.  User 

inputs  include  an  initial  demand  rate,  a  maximum  supply  level,  a 

\ 
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safety  supply  level,  a  critical  supply  level  (just  enough 
supplies  to  enable  the  user  to  withdraw  and  return  to  a  safe 

haven),  and  an  essentiality  priority  of  the  user  in  relation  to 
other  users  on  the  same  pipeline. 

Initially,  the  users  are  assumed  to  be  stocked  to  their 
maximum  supply  levels,  and  an  initial  pipeline  operation  is  set 
up  so  that  the  ISP  can  meet  all  the  demands  of  its  associated 
users.  ISP  inputs  include  a  maximum  storage  capacity,  an 

emergency  supply  level,  a  critical  supply  level,  and  it3  own 
supply  demand  rate.  The  initial  pipeline  operation  dispatches 
cargo  carriers  on  a  periodic  basis  such  that  a  cargo  carrier 

arrives  and  transfers  supplies  to  the  ISP  just  at  the  time  when 

the  ISP's  supply  level  drops  to  the  emergency  level.  Thus,  under 
the  initial  conditions,  user  demands  are  being  met,  their  supply 
levels  remain  at  their  maximum  supply  levels,  and  the  ISP  does 
not  have  to  draw  from  its  emergency  supplies.  This  pipeline 
operation  continues  until  a  contingency  occurs,  where  a 
contingency  reflects  a  change  in  a  user  demand  rate.  At  this 
time,  the  pipeline  operation  is  modified  so  that  the  ISP  will  be 
capable  of  meeting  the  new  demand  once  the  new  pipeline  operation 
is  in  effect.  In  the  interim  period,  several  things  could  occur. 

If  the  contingency  is  an  increase  in  demand,  then  the  ISP  may 
have  to  begin  drawing  from  its  emergency  supplies  at  some  time. 
During  this  interim  period,  cargo  carrier  arrivals  will  be  more 
frequent,  since  expected  shortfalls  will  have  to  be  recovered. 
If,  during  this  period,  the  ISP  has  to  draw  from  emergency 
supplies  and  cannot  satisfy  the  user’s  demands  (i.e.,  its  supply 
level  would  reach  the  critical  supply  level  before  the  arrival  of 
the  next  cargo  carrier) ,  then  the  user  supply  rates  are  decreased 
in  a  way  that  takes  into  account  their  essentiality  priority 
numbers.  In  this  case,  user  supply  levels  will  decrease,  and  one  * 
or  more  may  drop  below  their  safety  levels.  If  this  occurs,  the 
affected  user’s  essentiality  priority  will  be  assumed  at  unity, 
and  supply  rates  will  be  readjusted.  Also  a  user  supply  level 
may  eventually  reach  the  critical  level,  and,  in  that  case,  the 
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user  is  assumed  to  withdraw.  Because  the  ISP  will  no  longer  have 
to  supply  that  user,  it  can  increase  the  supply  rates  of  the 
remaining  users.  Also,  this  decrease  i.n  total  demand  will  impose 
a  requirement  to  modify  the  planned  pipeline  operation,  which  has 
not  yet  even  stabilized.  Furthermore,  user  withdrawal  due  to 
depletion  of  one  class  of  supplies  will  also  affect  the  pipelines 
that  serviced  that  user  for  the  other  classes  of  supplies.  This 
represents  the  only  dependency  between  the  three  pipelines. 

The  pipeline  operation  continues  in  the  above  manner  until 
one  of  four  events  occurs:  an  input-specified  duration  time  has 
been  reached;  all  users  have  withdrawn;  an  ISP's  supply  level 
will  drop  below  its  critical  level  before  the  arrival  of  the  next 
cargo  carrier;  or  all  contingencies  have  been  processed,  and  each 
pipeline  operation  has  reached  stabilization. 

The  output  of  the  module  consists  of  four  tables  for  each 
pipeline.  The  first  table  specifies  the  times  and  reasons  for 
the  occurrence  of  selected  events,  such  as  when  a  user  supply 
level  drops  below  its  safety  level,  a  user  withdraws,  a  cargo 
carrier  arrives  at  an  ISP,  and  so  on.  The  second  table  specifies 
the  supply  levels  of  the  ISP  and  the  users  at  the  time  of 
occurrence  of  an  event  and  at  predetermined  time  intervals.  The 
third  table  just  prints  out  the  supply  levels  at  the 
predetermined  time  intervals.  The  fourth  table  prints  out  the 
supply  rates  of  the  ISP  and  users  at  the  beginning  of  the 
operation  and  at  each  time  that  at  least  one  of  these  supply 
rates  changes  value.  This  latter  table  will  provide  the  required 
inputs  to  BALFRAM,  where  one  or  more  of  the  users  could  represent 
supply  nodes  within  the  BALFRAM  scenario. 

A  detailed  description  of  the  SUPPLY  DISTRIBUTION  MODULE  is 
presented  in  the  next  section  of  this  chapter.  A  sample  problem 
that  illustrates  the  use  of  the  module  is  discussed  in  Section  C. 
In  Section  D,  the  limitations  of  the  module  are  discussed, 
indicating  feasible  areas  for  future  improvements. 
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B.  Module  Description 

The  SUPPLY  DISTRIBUTION  MODULE  consists  of  the  main  program 
(PIPLIN)  and  four  subroutines  (REVISE,  NEXTEV,  ALLOC,  and 
SHTFAL).  Figures  IV— 1  to  IV-10  present  logic  flowcharts  of 
program  PIPLIN  and  Figures  IV-11  to  IV— 1 4  present  logic 
flowcharts  for  the  respective  subroutines.  The  appendix  to  this 
report  provides  an  alphabetical  listing  of  all  the  module 
nomenclature  and  a  complete  listing  of  the  module  computer 
program. 

The  module  can  essentially  be  broken  down  into  14  functional 
processing  sections:  Initialization,  Control,  Cargo  Carrier 

Arrival  Processing,  ISP  Emergency  Supply  Level  Processing,  User 
Safety  Level  Processing,  User  Withdrawal  Processing,  Contingency 
Event  Processing,  Routine  Printout  Processing,  Scheduled  Run 
Termination  Processing,  Output  Processing,  Subroutine  REVISE, 
Subroutine  NEXTEV,  Subroutine  ALLOC,  and  Subroutine  SHTFAL.  In 
the  description  of  the  module  that  follows,  each  of  these 
processing  sections  is  discussed  in  turn. 

The  basic  time  units  used  in  the  modules  are  in  terms  of 
days.  Thus,  the  rates  assumed  are  daily  rates.  The  general 
indexing  convention  used  in  the  module  description  is  as  follows: 

P  =  a  pipeline  number  (P  =  1,2,  or  3) 

I  =  user  number  (I  z  2,  ...  ,  NB  where  NB  denotes 
the  number  of  users,  a  program  input) 

J  z  cargo  carrier  number  (J  z  1...,  NTC(P)  where 

NTC(P)  denotes  the  number  of  cargo  carriers 
presently  assigned  to  pipeline  P,  a  program 
variable) 

NCO  z  contingency  event  number  (NCO  z  1,  ...,  NOC 

where  NOC  is  the  number  of  planned 
contingencies,  a  program  input) 

In  some  cases,  the  index  I  may  assume  values  NB1  s  NB  +  1, 
NB2  =  NB  +  2,  and  NB3  =  NB  +  3,  which  respectively  refer  to  the 
ISP,  a  contingency,  and  a  scheduled  printout  or  run  termination. 
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Initialization  (Fig.  IV-1) 

The  module  is  initiated  by  reading  in  a  set  of  inputs 
for  a  given  problem.  Table  IV-1  presents  a  summary  listing  of 
the  input  data.  The  detailed  program  inputs,  including  format 
descriptions,  are  specified  in  the  appendix.  At  this  time,  the 
output  table  headings  are  printed  out.  There  is  a  total  of 
twelve  output  tables  generated  by  the  module,  four  for  each 
pipeline.  For  a  given  pipeline,  the  first  table  represents  an 
"Event  Chronology"  (the  possible  event  types  are  described  later 
in  this  section).  Anytime  an  event  occurs  that  affects  the  given 
pipeline,  the  table  indicates  the  time  of  occurrence,  the  event 
type  number,  and  the  event  description.  Scheduled  printout 
events  are  not  included,  because  they  have  no  effect  on  the 
pipeline  operation.  The  second  table  portrays  "Event  Sequenced 
Supply  Levels."  Anytime  an  event  occurs,  including  scheduled 
printout  events,  the  supply  levels  for  the  ISP  and  each  user  are 
tabulated.  For  Cargo  Carrier  Arrival  Events,  supply  levels  are 
tabulated  at  both  the  time  of  arrival  and  time  of  departure  of 
the  cargo  carrier,  neglecting  the  cargo  unloading  time.  The 
third  table  portrays  "Time  Sequenced  Supply  Levels."  This  simply 
tabulates  the  ISP  and  user  supply  levels  at  the  scheduled 
printout  times.  The  fourth  table  portrays  "Supply  Rate 
Variations."  Whenever  the  supply  rate  changes,  the  time  of 
change,  the  event  type  number  instigating  the  change,  and  the 
supply  rates  for  the  ISPS  and  each  user  are  tabulated.  These 
Supply  Rate  Variation  tables  provide  the  link  between  this  module 
and  the  main  BALFRAM. 

The  next  step  is  to  establish  the  static  pipeline  flow 
parameters  for  each  pipeline.  This  initial  pipeline  operation  is 
set  up  so  that  the  ISP  can  meet  all  the  demands  of  the  users  and 
not  have  to  draw  from  its  emergency  supplies.  For  a  given 
pipeline,  the  procedure  for  accomplishing  this  is  as  follows. 
First,  the  total  demand  rate  on  the  ISP,  denoted  by  MD(P),  is 
determined  by  summing  up  the  individual  user  demand  rates 
specified  by  input  as  BIR(I,P),  including  the  ISP's  own  demand 
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FIGURE  IV-1.  LOGIC  FLOWCHART  (INITIALIZATION) 
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Table  IV- 1 


MODULE  INPUTS 


Descriptor 

Variable 

Name 

Scheduled  Printout  Inputs 

Printout  interval  (days) 

TP 

Scheduled  run  duration  (days) 

TDUR 

SudpIv  Source  Inputs  per  Pipeline 

Pipeline  name 

PN(P) 

Cargo  carrier  capacity  (ST  or  kbbl) 

SCC(P) 

Cargo  carrier  speed  (knots) 

SCS(P) 

Cargo  carrier  loading  rate  (ST/day  or  kbbl/day) 

SCL(P) 

Cargo  preparation  rate  (ST/day  or  kbbl/day) 

SPR(P) 

Recycle  down  time  (days) 

SDT(P) 

ISP  Inputs  per  Pipeline 

Storage  capacity  (ST  or  kbbl) 

MSC(P) 

Cargo  carrier  unloading  rate  (ST/day  or 

kbbl/day) 

MSU(P) 

Own  supply  demand  rate  (ST/day  or  kbbl/day) 

MDR(P) 

Emergency  stores  level  (ST  or  kbbl) 

MES(P) 

Critical  stores  level  (ST  or  kbbl) 

MCS(P) 

Transit  distance  between  supply  source  and  ISP 

(nmi) 

MSD(P) 

Order  time  (days) 

MOT(P) 

User  Inputs  per  Pipeline 

Number  of  users  (same  for  each  pipeline) 

NB 

User  I-initial  demand  rate  (ST/day  or  kbbl/day) 

BIR(I,P) 

User  I-initial  essentiality  priority  number 

BIP( I,  P) 

User  I-maximum  supply  level  (ST  or  kbbl) 

BML( I,  P) 

User  I-safety  supply  level  (ST  or  kbbl) 

BSL( I, P) 

User  I-critical  supply  level  (ST  or  kbbl) 

BCL(  I,  P) 

Contingency  Inputs 

Number  of  contingencies 

NOC 

User  number  associated  with  NCOth  contingency 

CUN(NCO) 

Time  at  which  NCOth  contingency  occurs  (days) 

TC(NCO) 

User  demand  rate  for  pipeline  P  after  occurrence 

of  NCOth  contingency  (ST/day  or  kbbl/day) 

CUD(NCO,  P) 

User  essentiality  priority  number  for  pipeline  P 

after  occurrence  of  NCOth  contingency 

CUP(NCO,  P) 

ST  -  Short  Tons 

kbbl  -  Thousands  of  Barrels 
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rate  MDR(P).  Thus, 


NB 

MD(P)  =  MDR(P)  +  BIR(P) 
1=1 


(IV-1) 


Since  initially  all  demands  will  be  satisfied,  the  ISP  supply 
rate  SR(P)  is  set  equal  to  the  demand  rate.  Thus, 


SR(P)  =  HD(P) 


(IV-2) 


For  subsequent  use,  the  user  demand  rate  HDP(P)  and  supply  rate 
SRP(P)  are  required.  These  are  given  as  follows: 


MDP(P)  =  MD(P)  -  MDR(P)  (IV-3) 


SRP(P)  =  SR(P)  -  MDR(P)  (IV—4) 


The  module  next  establishes  the  required  cycle  time  for  a  cargo 
carrier  with  a  full  load.  This  includes  the  round  trip  transit 
time  between  the  supply  source  and  the  ISP,  the  cargo 
preparation-for-shipment  time,  the  cargo  carrier  loading  and 
unloading  times  at  the  supply  source  and  ISP  respectively,  and 
the  recycle  down  time  for  the  cargo  carrier.  This  latter  factor 
includes  sufficient  time  for  cargo  carrier  maintenance,  liberty 
for  the  crew,  and  other  activities  required  between  cruises. 
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This  cycle  time,  denoted  by  TCY(P),  is  computed  as  follows: 


TCY (P)=SCC(P) 


1 


SPR(P) 
2  «  MSD(P) 


24  •  SCS(P) 


SCL(P) 
+  SDT(P) 


+ 


MSU(P) 


(IV-5) 


where 


SCC(P)  =  cargo  carrier  capacity 
SPR(P)  =  cargo  preparation  rate 
SCL(P)  =  cargo  loading  rate  at  the  supply  source 
MSU(P)  =  cargo  unloading  rate  at  the  ISP 
MSD(P)  =  transit  distance  between  supply  source 
and  ISP 

SCS(P)  =  cargo  carrier  speed 
SDT(P)  =  recycle  down  time. 


The  above  parameters  are  all  program  inputs.  The  module  then 
calls  on  subroutine  REVISE  to  determine  the  necessary  pipeline 
flow  parameters.  These  computations  are  described  later  in 
Section  11,  Subroutine  REVISE.  The  principal  outputs  of  this 
subroutine  are:  NC(P),  the  number  of  cargo  carriers  required  to 
maintain  the  pipeline  operation;  CL(P),  the  cargo  carrier  load 
which  may,  in  some  cases,  be  less  than  its  full  capacity;  and 
TR(P),  the  separation  time  between  cargo  carriers  (that  is,  the 
time  between  arrival  of  cargo  carriers  at  the  ISP).  At  this 
juncture,  it  is  assumed  that  a  cargo  carrier  has  just  departed 
from  the  ISP  so  that  the  ISP  supply  level  SL(P)  is  at  the  maximum 
storage  capacity.  That  is, 


SUP)  =  MSC(P) 


CIV-6) 


45 


here  MSC(P)  is  the  input-specified  ISP  storage  capacity.  Also, 
an  indicator  variable  ESP(P)  is  set  equal  to  zero  to  signify  that 
the  ISP  is  not  drawing  from  its  emergency  supplies. 

The  next  function  performed  by  the  module  is  to 
schedule  the  arrival  of  all  the  cargo  carriers  assigned  to  the 
pipeline.  For  computational  purposes,  it  is  actually  required  to 
schedule  the  arrival  of  one  additional  cargo  carrier  (that  is,  to 
schedule  the  second  arrival  of  the  first  scheduled  cargo 
carrier).  The  variable  NTC(P) 

r  NC(P)  +  1  denotes  the  number  of  scheduled  arrivals  maintained 
in  module  storage.  Associated  with  each  cargo  carrier  arrival 
time,  denoted  by  DT(J,P),  is  also  the  cargo  carrier  load,  denoted 
by  DC(J,P).  At  the  onset,  these  variables  are  given  by  the 
following  equations,  where  J  ranges  from  1  to  NTC(P): 


DT( J,P)  =  J.TR(P)  (IV-7) 


DC ( J , P )  =  CL(P)  (IV-8) 

where  TR(P)  and  CL(P)  were  computed  in  subroutine  REVISE,  as 
indicated  above. 

The  remainder  of  this  portion  of  the  module  is 
concerned  with  the  initializing  of  the  remaining  program  and 
pipeline  operating  variables.  The  module  is  an  event-sequenced 
model.  That  is,  the  time  variable  is  incremented  by  the 
occurrence  of  an  event.  Thus,  module  computations  are  performed 
only  at  the  time  of  occurrence  of  specific  events.  The  variable 
ET  denotes  an  event  type.  The  seven  event  types  included  in  the 
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module  are  as  shown  in  the  following  table. 


£T  Event  Type 

1  Cargo  carrier  arrival 

2  ISP  begins  drawing  from  emergency 
supplies 

3  User's  supply  level  drops  down  to  safety 
level 

4  User's  supply  level  reaches  critical 
level  (user  withdraws) 

5  Contingency  occurs 

6  Scheduled  printout 

7  Scheduled  run  termination 


The  array  SE(I,P)  denotes  the  next  type  of  event  associated  with 
user  I,  relative  to  pipeline  P,  and  the  array  TE(I,P)  stores  the 
time  of  occurrence  of  this  event.  Initially  SE(I,P)  is  set  equal 
to  zero  for  each  I,  which  indicates  that  there  is  no  next  event 
associated  with  the  user,  and  TE(I,P)  is  set  equal  to  a  very 

9 

large  number  (1  x  10  ).  It  should  be  noted  here  that,  for  users, 
only  Event  Types  3  and  4  are  applicable,  that  is,  SE(I,P)  can 
only  assume  the  event  type  values  of  3  or  4,  in  addition  to  the 
no  event  value  of  zero.  Although  a  contingency  event  (ET  =  5)  is 
user-dependent,  it  is  treated  as  a  special  case.  These  arrays 
also  contain  three  additional  elements.  The  first  represents  an 
ISP-related  event  and  has  an  index  value  of  NB1  =  NB+1,  where  NB 
is  the  number  of  users.  At  the  onset,  the  next  ISP  related  event 
will  be  the  arrival  of  the  first  cargo  carrier.  Thus,  SE(NBI.P) 
is  3et  equal  to  1,  and  TE(NB1,P)  ir  set  equal  to  the  scheduled 
arrival  time  of  the  first  cargo  carrier,  DT(1,P).  Note  here  that 
SE(NB1,P)  can  only  assume  the  values  of  1  or  2,  the  arrival  of  a 
cargo  carrier  or  the  ISP  beginning  to  draw  from  its  emergency 
supplies.  The  second  additional  element  represents  a  contingency 
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event  and  has  an  index  value  of  NB2  =  NB+2.  The  event  type  for 
this  element  is  always  a  contingency  event,  so  that  SE(NB2,P)  =  5 
at  all  times.  Initially  the  time  of  occurrence  of  the  next 
contingency  event  is  set  equal  to  the  time  of  occurrence  of  the 
first  contingency  as  specified  by  input.  That  is,  TE(NB2,P)  = 
TC(1).  The  contingency  event  counter  NCO  is  also  set  equal  to 
one.  The  third  additional  element  represents  a  scheduled  run 
control  operation  and  has  an  index  value  NB3  =  NB  +  3*  Event 
Types  6  and  7  are  associated  with  SE(NB3,P),  and  initially 
SE(NB3,P)  =  6,  with  TE(NB3,P)  =  TP,  the  scheduled  printout 

interval . 

There  are  several  other  program  variables  initialized 
at  this  point.  The  current  time  variable  CT  is  set  equal  to  0.0, 
and  the  current  event  variable  ET  is  set  equal  to  zero,  which 
indicates  that  this  is  the  start  of  the  run.  A  contingency 
pipeline  counter  IC  is  set  equal  to  zero,  as  is  also  a  user 
withdrawal  indicator  IW.  IC  is  used  in  the  processing  of 
contingency  events  (Section  7),  and  IW  is  used  in  the  processing 
of  user  withdrawal  events  (Section  6).  Descriptions  of  their  use 
are  deferred  until  the  processing  of  the  respective  events  are 
discussed . 

The  additional  pipeline  variables  to  be  initialized  are 
user-oriented,  with  the  exception  of  the  last  event  time  TLE(P), 
which  is  set  equal  to  0.0.  The  user  variables  to  be  initialized 
are  the  user  demand  rate  BR(I,P),  the  user  essential  priority  (in 
relation  to  other  users)  BP(I,P),  the  user  supply  level  BL(I,P), 
the  user  supply  rate  BS(I,P),  and  a  user  in-game  ilndicator 
BIG(I).  The  latter  is  initially  set  equal  to  one  to  indicate 
that  the  user  is  active.  Should  a  user  eventually  withdraw,  this 
indicator  would  then  be  set  equal  to  zero.  The  other  user 
variables  are  set  equal  to  their  respective  input-specified 
values.  Thus, 


BR(I.P)  =  BIR(I.P) 


(IV-9) 
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BP(I.P)  =  BIP(I,P) 


(IV-10) 


BL( I, P)  =  BML(I.P) 


(IV-11) 


BS ( I , P )  =  BIR(I,P) 


(IV-12) 


The  latter  equation  holds  true  because,  at  the  onset, 
user  demands  are  being  satisfied. 

The  final  operations  performed  under  the  initialization 
function  are  to  print  out  the  supply  levels  and  supply  rates  at 
time  zero  on  Output  Tables  2,3,  and  4  for  each  pipeline. 

The  module  is  now  ready  to  begin  the  actual  pipeline 
operations,  and  proceeds  to  the  control  function. 

2.  Control  (Fig.  IV-2) 

As  mentioned  before,  the  module  is  an  event-sequencing 
type.  That  is,  the  time  variable  increases  in  accordance  with 
the  time  of  the  next  event.  The  control  function  simply 
establishes  the  time  and  character  of  the  next  event  to  be 
processed.  The  arrays  TE(I,P)  contain  the  time  of  the  next  event 
for  each  user  and  also  for  the  ISP,  contingencies,  and  scheduled 
run  control  operations  for  each  pipeline.  The  associated  array 
SE(I,P)  identifies  the  type  of  event  to  be  processed.  At  the 
completion  of  processing  an  event,  the  module  will  first  set  the 
last-event  time  for  the  associated  pipeline  TLE(P)  equal  to  the 
current  time.  It  then  scans  the  TE(I,P)  arrays  to  determine  the 
time  of  the  next  event  and  sets  the  current  time  equal  to  this 
next  event  time.  Thus, 
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*£T  CURRENT  TIME  EQUAL  TO  EVENT  TIME 
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FIGURE  IV-2.  LOGIC  F LOWCHART  (CONTROL) 


CIV-13) 


CT  =  min  {  TE(I,P)  } 

(1=1. . . ,NB3;P=1,2,3) 


The  value  of  P  such  that  TE(I,P)  achieves  this  minimum  identifies 
the  pipeline  associated  with  the  event  and  the  associated  value 
of  I  identifies  the  user  if  I  =  NB,  or  identifies  the  event  as  an 
ISP-dependent  event  (I  =  NB1),  a  contingency  event  (I  =  NB2) ,  or 
a  scheduled  run  control  event  (I  =  NB3).  The  variables  JP  and  JE 
are  set  equal  to  the  particular  values  of  P  and  I,  respectively, 
generating  the  event.  Thus,  SE(JE,JP)  identifies  the  type  of 
event  to  be  processed,  so  that  the  event  type  variable  ET  is  set 
equal  to  SE(JE,JP). 

If  the  event  to  be  processed  is  a  contingency  event  (ET 
=  5),  the  variable  JT  is  set  equal  to  the  user  number  instigating 
the  event,  that  is  JT  =  CUN(NCO).  If  this  user  is  no  longer 
active  (BIG(JT)  =  0),  then  this  event  will  not  occur,  and  the 
contingency  event  counter  NCO  is  incremented  by  one.  Also,  for 
each  pipeline,  the  next  contingency  event  time  TE(NB2,P)  is  set 
equal  to  the  time  of  occurrence  of  the  next  contingency.  That 
i3,  TECNB2.P)  =  TC(NCO)  for  each  P.  In  this  case,  the  module 
then  again  scans  the  TE(I,P)  arrays  to  determine  the  time  of  the 
next  event  and  repeats  the  procedure  described  above.  Otherwise, 
the  module  sets  the  current  time  equal  to  the  event-occurrence 
time  (CT  =  TE(JE,JP))  and  computes  the  present  supply  levels  for 
the  pipeline,  inducing  the  event  according  to  the  following 
equation 

BL(I,P)  =  BL(I, P)  -  (BR(I, P)  -  BS(I,P)) •  (CT-TLE(P))  (IV-14) 

.  SUP)  =  SUP)  -  SR(P)  •  (CT-TLE(P) )  (IV-15) 


If  this  event  is  not  a  contingency,  then  the  module  prints  out 


these  new  supply  levels  on  Table  2  for  the  pipeline  associated 
with  this  event  (for  a  contingency  event,  each  pipeline  may  or 
may  not  be  affected,  so  the  supply  level  printouts  are  deferred 
until  the  event  is  actually  processed).  The  module  then  proceeds 
to  process  the  event  identified  by  ET  in  accordance  with  the 
associated  event  processing  described  in  the  next  seven  sections. 

3.  Cargo  Carrier  Arrival  Processing  (Fig.  IV-3) 

On  the  arrival  of  a  cargo  carrier  at  an  ISP,  the  ISP 
supply  level  is  increased  by  the  amount  of  the  cargo  carrier 
load.  That  is 


SUP)  =  SUP)  +  DC  ( 1 ,  P )  (IV-16) 

Where  P  denotes  the  pipeline  that  is  affected  by  this  cargo 
carrier  arrival.  That  is,  P  +  JP,  where  JP  identified  the 
pipeline  associated  with  this  event  previously  in  the  control 
processing.  The  module  then  prints  out  the  message  "CARGO 
CARRIER  ARRIVAL  AT  ISP"  on  the  Event  Chronology  (Table  2)  for 
this  pipeline.  For  subsequent  computations,  the  previous 
pipeline  supply  rate  SROLD  is  stored,  where 

SROLD  =  SR( P)  (IV-17) 


Also,  a  pipeline  stabilization  indicator  ITERM(P)  is  set  equal  to 
zero,  which  will  later  signify  that  the  pipeline  operation  has 
not  reached  stabilization.  The  module  then  checks  to  see  if 
there  are  any  interim  cargo  carriers  in  the  pipeline  operation. 
The  variable  NIC(P)  denotes  the  number  of  such  cargo  carriers. 
Interim  cargo  carriers  in  the  pipeline  arise  when  there  is  a 
change  in  the  static  pipeline  operation,  which  can  occur  when 
there  is  a  contingency  event  or  when  a  user  withdraws. 

If  there  are  no  interim  carriers  in  this  pipeline 
(NIC(P)  =  0),  then  the  pipeline  is  in  a  stabilized  state,  and  the 
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FIGURE  IV-3.b  LOGIC  FLOWCHART  (CARGO  CARRIER  ARRIVAL  PROCESSING) 
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FIGURE  IV-3.d  LOGIC  FLOWCHART  (CARGO  CARRIER  ARRIVAL  PROCESSING) 
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stabilization  indicator  ITERM(P)  is  set  equal  to  one.  If  there 
are  no  more  contingency  events  to  be  processed  (NCO  >  NOC) ,  and 
all  three  pipeline  operations  have  reached  stabilization 
( ITERM(P)  =  2  for  each  pipeline),  the  computer  run  will  be 
terminated.  In  this  case,  the  event  type  ET  will  be  set  equal  to 
seven  (run  termination),  and  the  message  ’’RUN  TERMINATED — LAST 
CONTINGENCY  HAS  BEEN  STABILIZED"  will  be  printed  out  on  the  Event 
Sequenced  Supply  Level  table  (Table  2)  and  the  Time  Sequenced 
Supply  Level  table  (Table  3)  for  each  pipeline,  and  the  supply 
rates  will  be  printed  out  on  the  Supply  Rate  Variation  table 
(Table  4)  for  each  pipeline.  The  module  then  proceeds  to  Output 
Processing  (Section  10).  If  there  is  another  contingency  to  be 
processed,  or  if  at  least  one  pipeline  operation  has  not  reached 
stabilization,  then  the  module  will  continue  running.  In  this 
case,  cargo  carrier  arrivals  are  updated,  and  a  new  cargo  carrier 
is  scheduled  for  the  pipeline  operation.  This  accomplished  as 


follows,  where  J  ranges  from  2  to  NTC(P): 

DT(J-l.P)  =  DT(J.P)  ( IV-18) 
DC(J-l.P)  =  DC(J.P)  ( I V— 1 9 ) 
DT(NTC(P),P)  =  DT(NTC(P)-1 ,P)+TR(P)  (IV-20) 
DC(NTC(P) ,P)  =  DC(NTC(P)-1,P>  (IV-21) 


The  next  cargo  carrier  arrival  event  time  TE(NB1,P)  is  also 
updated  by  setting  it  equal  to  the  new  value  of  DT(1,P).  At  this 
point,  the  module  prints  out  the  supply  levels  on  the  Event 
Sequenced  Supply  Level  table  for  this  pipeline  and  returns  to 
Control  (Section  2). 

If  there  are  interim  carriers  in  the  present  pipeline, 
then  the  processing  of  this  event  follows  another  course.  First, 
the  cargo  carrier  arrivals  are  updated  in  accordance  with  Eq. 


(IV-17)  and  ( IV— 1 8)  above.  Because  the  present  arriving  cargo 
carrier  is  an  interim  carrier,  the  number  of  interim  cargo 
carriers  NIC(P)  and  the  total  number  of  cargo  carriers  in  the 
pipeline  NTC(P)  are  each  decreased  by  one.  No  new  cargo  carriers 
are  scheduled,  because  the  pipeline  operation  has  not  yet 
stabilized.  The  next  cargo  carrier  arrival  event  time  TE(NB1,P) 
is  also  updated  by  setting  it  equal  to  the  time  of  arrival  of  the 
next  cargo  carrier,  the  new  value  of  DT(1,P).  A  test  is  then 
made  to  determine  if  the  ISP  supply  level  is  greater  than  its 
emergency  supply  level. 

If  the  1ST  supply  level  is  greater  than  its  emergency 
supply  level  (SL(P)  >MES(P)),  then  the  ISP  can  (for  the  present, 
anyway)  satisfy  all  demands.  In  this  case,  the  ISP  supply  rate 
SR(P)  is  set  equal  to  the  total  demand  rate  MD(P),  each  active 
user's  supply  rate  BS(I,P)  is  set  equal  to  its  demand  rate 
BR(I,P) ,  and  the  user's  next  event  time  TE(I,P)  is  set  equal  to  a 
large  number.  If  the  ISP's  new  supply  rate  is  different  than 
before  (SR(P)?*  SROLD) ,  then  the  supply  rates  are  printed  out  on 
the  Supply  Rate  Variation  table  for  this  pipeline.  At  this 
point,  it  may  be  that  the  cargo  carrier's  load  was  greater  than 
the  ISP  could  handle.  This  excess  is  called  the  present  supply 
surplus  SFM1 .  It  can  be  distributed  immediately  to  any  users 
with  supply  shortfalls,  as  will  be  described  later.  Thus, 


.1  °- 

|  SL(P)-MSC(P) 


if  SL(P)  <  MSC(P) 
if  SL (P)  >  MSC(P) 


(IV-22) 


The  next  step  is  to  determine  the  amount  of  future  supply  surplus 
SFM2  that  may  be  available  before  the  next  cargo  carrier  arrival. 


58 


T’nis  is  determined  by  the  following  equation 


SFM2  =  max  Jo.,  SL(P)-SRCP) .  (DT( 1 .P)-CT)-MCS(P) }  (IV-23) 

The  total  amount  of  supply  surplus  SFM  that  oan  be  distributed  at 
this  time  is  given  by: 


SFM  =  SFM1  +  SFM2 


(IV-24) 


If  SFM  is  greater  than  zero  and  there  are  users  with  supply 
shortfalls,  then  this  supply  surplus  is  distributed  to  users  in 
accordance  with  the  procedures  described  in  Subroutine  SHTFAL 
(Section  14).  Otherwise  the  cargo  carrier  will  return  to  its 
home  base  with  an  amount  of  supplies  equal  to  SFM1.  Because  the 
ISP  supply  level  is  greater  than  its  emergency  supply  level,  its 
emergency  supply  level  indicator  ESP(P)  is  set  equal  to  zero  to 
signify  that  the  ISP  is  not  drawing  from  emergency  supplies.  If 
the  present  indicated  ISP  supply  level  SL(P)  is  greater  than  its 
maximum  storage  capacity  MSC(P),  then  SL(P)  is  now  set  equal  to 
MSC(P).  The  next  step  is  to  determine  if  the  ISP  will  have  to 
draw  from  its  emergency  supplies  before  the  arrival  of  the  next 
cargo  carrier.  This  is  accomplished  by  first  determining  the 
time  TEM  at  which  the  ISP  would  begin  drawing  from  its  emergency 
supplies  under  the  present  ISP  supply  rate,  assuming  no  cargo 
carrier  arrives  before  then.  This  is  given  by 


TEM 


CT+ 


SL (P)  -  MES(P) 
SR(P) 


(IV-25) 


If  TEM  s  DT(1,P),  then  a  cargo  carrier  will  arrive  before  this 
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occurs,  and  the  ISP's  next  event  type  will  be  a  cargo  carrier 
arrival,  so  that  SE(NB1,P)  =  1  and  TE(NB1,P)  =  DT(I.P). 
Otherwise,  the  ISP's  next  event  type  will  be  its  beginning  to 
draw  from  emergency  supplies,  so  SE(NB1,P)  =  2  and  TE(MBI.P)  = 
TEM.  At  this  point,  the  module  prints  out  the  supply  levels  on 
the  Event  Sequenced  Supply  Level  table  for  this  pipeline  and 
returns  to  Control  (Section  2)  to  determine  the  next  event  to  be 
processed . 

If  the  ISP  supply  level  is  not  greater  than  its 
emergency  supply  level  (SL(P)  _<  MES(P) ) ,  then  the  ISP  may  or  may 
not  be  able  to  satisfy  all  user  demands.  Thus,  the  maximum 
allowable  supply  rate  SRT  for  this  pipeline  is  computed  as 
follows 


SL(P)  -  MCS(P)  (IV-26) 

DT(1,P)-CT 


At  this  supply  rate,  the  ISP  supply  level  would  just  drop  to  its 
critical  level  at  the  time  of  arrival  of  the  next  cargo  carrier. 
If  this  maximum  allowable  supply  rate  is  greater  than  or  equal  to 
the  total  demand  rate  (SRT  >_MD(P)),  then  the  remainder  of  the 
processing  of  this  event  is  the  same  as  in  the  previous  case 
where  the  ISP  supply  level  was  greater  than  its  emergency  supply 
level,  with  the  following  exceptions:  there  is  no  present  supply 
surplus  so  that  SFM1=0.;  the  ISP  emergency  supply  level  indicator 
ESP(P)  will  remain  equal  to  one;  and  the  next  event  type  fc**  this 
pipeline  will  be  a  cargo  carrier  arrival,  that  is,  SE(NB1,P)  =  1 
and  TE(NB1,P)  =  DT(1,P).  If,  on  the  other  hand,  the  ISP  cannot 
satisfy  all  demand  with  its  maximum  allowable  supply  rate  (SRT  < 
MD(P)),  then  a  check  is  made  to  determine  if  the  ISP  can  satisfy 
its  own  demand  (SRT  >  MDR(P)).  If  the  answer  is  no,  then  the 
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computer  run  will  be  terminated  as  the  ISP  would  have  to  withdraw 
before  the  arrival  of  the  next  cargo  carrier.  In  this  case,  the 
event  type  ET  will  be  set  equal  to  seven,  and  the  message,  "RUN 
TERMINATED— ISP  CANNOT  MAINTAIN  SELF-SUPPLY,  PIPELINE  PN(P)"  will 
be  printed  out  on  the  Event  Chronologies  for  each  pipeline,  where 
the  PN(P)  specified  in  the  message  is  the  pipeline  name  of  the 
pipeline  instigating  the  run  termination.  In  addition,  the 
supply  levels  will  be  printed  out  on  the  Event  Sequenced  Supply 
Level  table  and  the  Time  Sequenced  Supply  Level  table  for  each 
pipeline,  and  the  supply  rates  will  be  printed  out  on  the  Supply 
Rate  Variation  table  for  each  pipeline.  The  module  then  proceeds 
to  Output  Processing  (Section  10). 

If  the  ISP  can  satisfy  its  own  demand,  then  the  ISP 
supply  rate  SR(P)  is  set  equal  to  SRT,  and  the  allowable  user 
supply  rates  are  determined.  Subroutine  ALLOC  (Section  13) 
determines  weighting  factors  WB(I)  that  determine  the  amount  of 
the  expected  shortfall  to  be  allocated  to  each  user.  These 
weighting  factors  take  into  account  the  users'  demand  rates  and 
essential  priorities.  The  new  user  supply  rates  are  then 
computer  as  follows: 


BS(I,P)  =  BR(I,P)  -  WB( I ) • (MD( P)  -  SR(P))  (IV-27) 

The  next  step  is  to  call  on  Subroutine  NEXTEV  (Section  12)  to 
determine  the  next  event  times  and  types  for  each  user,  relative 
to  the  pipeline  being  processed.  If  the  ISP  supply  rate  has 
changed  from  its  previous  value  (SR(P)  ^  SROLD),  then  the  new 
supply  rates  are  printed  out  on  the  Supply  Rate  Variation  tabble 
for  this  pipeline.  The  ISP  emergency  supply  indicator  ESP(P)  for 
this  pipeline  remains  at  unity,  and  the  next  event  will  be  a 
cargo  carrier  arrival,  that  is,  SE(NB1,P)  =  1  and  TE(NB2,P)  1= 
DT(1,P).  The  supply  levels  are  then  printed  out  on  the  Event 
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Sequenced  Supply  Level  table  for  this  pipeline,  and  the  module 
returns  to  Control  (Section  2)  to  determine  the  next  event  to  be 
processed.  This  completes  the  Cargo  Carrier  Arrival  processing 
function . 


4.  ISP  Emergency  Supply  Level  Processing  (Fig.  IV-4) 

When  an  ISP's  supply  level  drops  below  its  emergency 
supply  level,  the  module  immediately  prints  out  the  message  "ISP 
DIPPING  INTO  EMERGENCY  SUPPLIES"  on  the  Event  Chronology  for  this 
pipeline.  It  also  sets  the  ISP's  emergency  supply  level 
indicator  ESP(P)  equal  to  one.  Next,  the  maximum  allowable 
supply  rate  for  the  ISP,  denoted  by  SRT,  is  computed  in  the  same 
manner  as  indicated  previously  in  Eq.  (IV-26). 

If  user  demands  can  still  be  satisfied  (SRT>  MD(P)), 
then  the  next  event  for  the  ISP  will  be  a  cargo  carrier  arrival, 
that  is,  SE(NB2,P)  =  1  and  TE(NBI)  =  DT(1,P).  The  module  then 
returns  to  Control  (Section  2)  to  determine  the  next  event  to  be 
processed. 

If  user  demands  cannot  be  satisfied,  the  ISP  supply 
rate  SR(P)  is  set  equal  to  its  maximum  allowable  supply  rate, 
SRT,  and  the  module  checks  to  see  if  the  ISP  can  satisfy  its  own 
demand  (SRT  .>  MDR(P)) .  If  the  answer  is  no,  then  the  computer  run 
will  be  terminated,  as  the  ISP  would  have  to  withdraw  before  the 
arrival  of  the  next  cargo  carrier.  In  this  case,  the  event  type 
ET  is  set  equal  to  seven,  and  the  message  'RUN  TERMINATED — ISP 
CANNOT  MAINTAIN  SELF-SUPPLY,  PIPELINE  PN(P)’  will  be  printed  out 
on  the  Event  Chronologies  for  each  pipeline,  where  the  PN(P) 
specified  in  the  message  is  the  name  of  the  pipeline  instigating 
the  run  termination.  In  addition,  the  supply  levels  will  be 
printed  out  on  the  Event  Sequenced  Supply  Level  table  and  the 
Time  Sequenced  Level  table  for  each  pipeline,  and  the  supply 
rates  will  be  printed  out  on  the  Supply  Rate  Variation  table  for 
each  pipeline.  The  module  then  proceeds  to  Output  Processing 
(Section  10). 

If  the  ISP  can  satisfy  its  own  demand,  the  allowable 
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user  supply  rates  and  the  next  event  times  and  types  for  each 
user  relative  to  the  pipeline  being  processed  are  determined  in 
the  same  manner  as  that  described  at  the  end  of  the  previous 
section.  The  new  supply  rates  are  printed  out  on  the  Supply  Rate 
Variation  table  for  this  pipeline,  and  then  the  module  returns  to 
Control  (Section  2)  to  determine  the  next  event  to  be  processed. 
This  completes  the  ISP  Emergency  Supply  Level  Processing. 

5.  User  Safety  Level  Processing  (Fig.  IV-5) 

When  a  user's  supply  level  drops  below  its  safety 
level,  the  module  prints  out  the  message  "SUPPLY  LEVEL  DROPS 
BELOW  SAFETY  LEVEL-USER  NUMBER  J£"  on  the  Event  Chronology  for 
this  pipeline.  For  subsequent  use,  the  user's  previous  supply 
rate  BSOLD  is  stored,  where 


BSOLD  =  BS( JE, P) 


CIV-28) 


with  JE  denoting  the  index  of  the  user  instigating  this  event. 
The  user's  essential  priority  BP(JE,P)  is  set  equal  to  four.  The 
module  next  determines  new  supply  rates  for  each  user  in  this 
pipeline  and  then  establishes  the  next  event  types  and  times  of 
each  user  relative  to  the  pipeline  being  processed.  These  are 
done  in  the  same  manner  as  that  described  at  the  end  of  Section  3 
(Cargo  Carrier  Processing).  If  the  supply  rates  change,  the  new 
supply  rates  are  printed  out  on  the  Supply  Rate  Variation  table 
for  this  pipeline,  and  then  the  module  returns  to  Control 
(Section  2)  to  determine  the  next  event  to  be  processed.  This 
completes  the  User  Safety  Level  processing. 

6.  User  Withdrawal  Processing  (Fig.  IV-6) 

When  a  user’s  supply  level  reaches  its  critical  level, 
the  user  has  just  enough  supplies  furnished  by  the 
event-instigating  pipeline  to  withdraw  from  its  assigned  station 
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FIGURE  IV-*»  LOGIC  FLOWCHART  (USER  WITHDRAWAL  PROCESSING) 
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»  ^ 


FIGURE  IV-6.b  LOGIC  FLOWCHART  (USER  WITHDRAWAL  PROCESSING) 
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FIGURE  IV-6.C  LOGIC  FLOWCHART  (USER  WITHDRAWAL  PROCESSING) 


and  return  to  a  safe  haven.  Thus,  the  user  is  assumed  to 
withdraw,  and  its  demands  on  the  ISP  no  longer  have  to  be 
satisfied.  At  this  time,  the  withdrawing  user’s  in-game 
indicator  BIG(JE)  is  set  equal  to  zero,  and  the  user  withdrawal 
indicator  IW  is  set  equal  to  one.  Because  a  user  withdrawal  will 
affect  each  pipeline  operation,  all  three  pipelines  are  subjected 
to  processing  for  this  event.  The  module  thus  sets  P=1  and 
begins  the  event  processing  for  the  first  pipeline. 

The  module  first  stores  the  previous  values  of  the 
pipeline’s  supply  rate  SROLD,  the  total  demand  rate  MDOLD,  and 
the  cargo  carrier  load  CLOLD,  for  the  static  pipeline  operation. 
That  is, 

SROLD  =  SR(P)  (IV-29) 

MDOLD  =  MD(P)  (IV-30) 

CLOLD  =  CL(P)  (IV-31) 

Next,  the  message  "SUPPLY  LEVEL  REACHES  CRITICAL  LEVEL  USER 
NUMBER  JE,  USER  WITHDRAWALS— INSTIGATING  PIPELINE-PN( JP)’’  on  the 
Event  Chronologies  for  each  pipeline,  where  JE  denotes  the  index 
of  the  instigating  user  and  JP  denotes  the  pipeline  associated 
wiith  the  supply  shortfall.  If  the  pipeline  being  processed  is 
not  the  one  causing  the  withdrawal  event,  the  present  ISP  and 
user  supply  levels  are  determined  in  accordance  with  Eq.  (IV-13) 
and  (IV-14).  These  are  then  printed  out  on  the  Event  Sequenced 
Supply  Level  table  for  this  pipeline  (for  the  pipeline  causing 
this  event,  this  supply  level  printout  was  already  done  in 
Control).  Next,  the  time  of  last  event  for  this  pipeline  TLE(P) 

is  set  equal  to  the  current  time,  CT.  The  module  then  computes 
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the  new  total  demand  rate  by  subtracting  out  the  withdrawing 
user's  demand  rate.  Thus, 


MD(P)  =  MD(P)  -  BR(JE.P)  (IV-32) 

The  instigating  user  is  now  withdrawn  from  the  pipeline  operation 
by  setting  its  supply  rate  BS(JE.P),  its  demand  rate  BR(JE,P), 
and  its  next  event  type  SE(JE,P)  to  zero.  Also,  this  user's  next 
event  time  TE(JE,P)  is  set  equal  to  a  large  number. 

The  module  then  checks  to  see  if  all  users  have  now 
withdrawn.  If  so,  the  event  type  ET  is  set  equal  to  seven  and 
the  message  "RUN  TERMINATED— ALL  USERS  HAVE  WITHDRAWN"  is  printed 
out  on  the  Event  Chronologies  for  each  pipeline.  In  addition, 
the  supply  level  will  be  printed  out  on  the  Event  Sequenced 
Supply  Level  table  for  each  pipeline,  and  the  supply  rates  will 
be  printed  out  on  the  Supply  Rate  Variation  table  for  each 
pipeline.  The  module  then  proceeds  to  Output  Processing  (Section 
10). 

If  there  are  still  active  users,  the  module  then  checks 
to  see  if  the  pipeline  being  processed  is  the  one  causing  the 
user  withdrawal.  If  it  is  not,  the  processing  is  transferred  to 
the  Contingency  Event  Processing  (Section  7),  where  the 
processing  parallels  that  of  a  contingency  event  in  which  a 
user's  demand  rate  is  decreased.  The  processing  activity  is 
described  in  that  section.  If  this  is  the  pipeline  causing  the 
user  withdrawal,  the  module  then  determines  if  the  revised  user 
total  demands  can  now  be  satisfied  by  the  ISP.  If  this  is  not 
the  case,  then  the  module  determines  new  supply  rates  for  each 
active  user  in  this  pipeline  and  then  establishes  the  next  event 
types  and  times  of  each  user  relative  to  the  pipeline  being 
processed.  These  are  done  in  the  same  manner  as  that  described 
at  the  end  of  Section  3  (Cargo  Carrier  Processing). 

If  user's  demands  can  be  met,  then  the  ISP  supply  rate 
SR(P)  is  set  equal  to  the  total  demand  rate  MD(P),  each  active 
user's  supply  rate  BS(I,P)  is  set  equal  to  its  demand  rate 
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BR(I,P),  and  their  next  event  times  TE(I,P)  are  set  equal  to  a 
large  number.  With  the  withdrawal  of  a  user,  a  supply  surplus 
may  possibly  be  accumulated  before  the  arrival  of  the  next  cargo 
carrier.  If  this  is  the  case  (SROLD  >MD(P)),  then  the  amount  of 
supply  surplus  is  determined  by  the  following  equation: 

SFM  =  (SROLD  -  MD(P) )  •  (DT(1,P)  -  CT)  (IV-33) 

This  supply  surplus  is  then  distributed  to  the  active  users 
according  to  the  procedures  described  in  Subroutine  SHTFAL 
(Section  14).  Because  user  supply  levels  have  changed,  these  new 
supply  levels  are  printed  out  on  the  Event  Sequenced  Supply  Level 
table  for  this  pipeline. 

In  each  case  above  involving  active  users,  the  ISP  and 
user  supply  rates  have  changed.  These  are  now  printed  out  on  the 
Supply  Rate  Variation  table  for  this  pipeline.  The  next  step  is 
to  determine  the  number  of  enroute  cargo  carriers.  To  do  this, 
it  is  first  required  to  determine  the  arrival  time  of  a 
hypothetical  cargo  carrier  that  would  be  in  a  load  preparation  at 
the  time  that  a  revised  supply  order  would  be  received  at  the 
supply  source.  This  arrival  time  is  determined  as  follows: 


TEM 


CT  +  CLOLD* 


—  + 


SPR(P)  SCL(P)  MSU (P) J 


MSD(P) 
24*  SCS(P) 


+  MOT(P) 


(IV-34) 


where  CLOLD  is  the  previous  static  pipeline  cargo  carrier  load 
for  this  pipeline,  MOT(P)  is  the  ISP  order  time,  and  the 

remaining  variables  are  as  indicated  following  Eq.  (IV-5)  in 
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Section  2.  Thus,  if  DT(J,P)<_  TEM,  then  this  Jth  cargo  carrier 
will  be  identified  as  an  iterim  cargo  carrier  and  will  remain  in 
the  cargo  carrier  arrival  schedule.  The  number  of  interim  cargo 
carriers  NIC(P)  will  be  set  equal  to  the  total  number  of  such 
cargo  carriers.  Subroutine  REVISE  (Section  11)  will  then  be 
called  upon  to  establish  the  new  static  pipeline  flow  parameters: 
that  is,  the  number  of  cargo  carriers  required  to  maintain  the 
pipeline  operation  NC(P);  the  cargo  carrier  load  for  each  of 
these  carriers  CL(P);  and  the  separation  time  between  cargo 
carriers  TR(P).  The  total  number  of  cargo  carriers  in  the 
pipeline  operation  NTC(P)  is  then  determined  as  follows: 

NTC(P)  =  NIC(P)  +  NC(P)  +  1  (IV-35'1 

where  it  should  be  recalled  that  one  extra  cargo  carrier  is 
scheduled  in  the  normal  pipeline  operation.  The  scheduled 
arrival  at  the  ISP  of  the  static  pipeline  cargo  carriers  and 
their  associated  loads  must  now  be  established.  These  are  given 
as  follows,  where  J  ranges  from  1  to  NC(P)  +  1: 

DT(NIC+J,P)  =  DT(NIC(P),P)  +  J  •  TR(P)  (IV-36) 


DC(NIC+J , P)  =  CL( P)  (IV-37) 

Since  a  user  withdrew,  any  shceduled  contingency  event 
associated  with  this  user  must  be  cancelled.  This  cancellation 
process  proceeds  as  follows.  A  no-event  indicator  IJ  is 
initially  set  equal  to  zero.  If  there  are  no  more  scheduled 
contingency  events  (NCO  >  NOC)  ,  the  the  time  of  the  next 
contingency  event  TE(NB2,P)  for  each  pipeline  is  Set  equal  to  a 
large  number.  If  there  are  more  scheduled  contingency  events, 
then  a  test  is  made  to  determine,  in  sequence,  if  the  scheduled 
contingency  event  involves  the  withdrawing  user.  If  the  answer 
is  no,  then  nothing  is  done.  If  the  answer  is  yes,  then  that 
contingency  event  is  eliminated  from  the  contingency  event 
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schedule,  and  the  remaining  contingency  events  are  moved  up  in 
the  scheduling  arrays.  If  JJ  denotes  the  contingency  index 
number  of  the  contingency  to  be  cancelled,  then  for  J  =  JJ  to  NOC 
and  for  all  IP, 


TC( JJ) =  TC( JJ+1 ) 

(IV-38) 

CUN( JJ) =  CUN( JJ+1 ) 

(IV-39) 

CUD( JJ, P)  =  CUD(JJ+1,P> 

(IV-40) 

CUP(JJ,P)  =  CUP(JJ+1,P) 

(IV-41) 

The  total  number  of  contingency  events  NOC  is  reduced  by  one  for 
each  cancellation  and  if  there  is  another  contingency  event 
involving  an  active  user,  then  the  no-event  indicator  IJ  is  set 
equal  to  one.  If  there  still  is  a  scheduled  contingency  event 
involving  the  event,  then  the  next  contingency  event  time 
TE(NB2,P),  for  each  pipeline,  is  set  equal  to  the  time  of  the 
next  scheduled  contingency  event.  Otherwise,  this  variable  is 
set  equal  to  a  large  number  for  each  pipeline. 

At  this  juncture,  the  processing  of  pipelines  not 
causing  the  user  withdrawal  returns  from  the  processing  that  was 
conducted  in  the  Contingency  Event  Proceessing  section.  If  there 
is  another  pipeline  to  be  processed,  then  the  pipeline  index  is 
incremented  by  one  and  this  pipeline  is  processed  as  described 
above,  beginning  with  the  second  paragraph  of  this  section. 
Otherwise,  the  user  withdrawal  indicator  IW  is  set  equal  to  zero 
and  the  module  returns  to  Control  (Section  2)  to  determine  the 
next  event  to  be  processed.  This  completes  the  User  Withdrawal 
processing  function. 

7.  Contingency  Event  Processing  (Fig.  IV-7) 

When  a  contingency  event  occurs,  each  pipeline  may  or 
may  not  be  affected.  Thus,  each  pipeline  will  be  subjected  to 
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FIGURE  IV-7J  LOGIC  FLOWCHART  (CONTINGENCY  EVENT  PROCESSING) 
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FIGURE  IV-7.C  LOGIC  FLOWCHART  (CONTINGENCY  EVENT  PROCESSING) 
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FIGURE  IV-7.e  LOGIC  FLOWCHART  (CONTINGENCY  EVENT  PROCESSING) 


FIGURE  IV-7.g  LOGIC  FLOWCHART  (CONTINGENCY  EVENT  PROCESSING) 
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independent  processing  at  the  time  of  occurrence  of  a 
contingency.  That  is,  three  contingency  events  are  scheduled, 
one  for  each  pipeline,  at  the  time  of  occurrence  of  a 
contingency.  The  processing  of  one  of  these  events  is  described 
now. 

The  variable  JE  is  used  to  denote  the  user  instigating 
the  contingency  event,  so  this  is  set  equal  to  CUN(NCO).  The 
module  then  stores  the  previous  values  of  the  ISP  supply  rate 
BSOLD ,  the  total  demand  rate  MDOLD,  the  static  pipeline  cargo 
carrier  load  CLOLD  and  the  instigating  user’s  essential  priority 
BPOLD.  The  contingency  pipeline  counter  IC  is  incremented  by  one 
and  the  time  of  the  next  contingency  event  for  the  pipeline  P 
being  processed  TE(NB1,P)  is  temporarily  set  equal  to  a  large 
number.  The  module  next  determines  the  possibly  new  total  demand 
rate  MD(P)  as  follows: 

MD( P)  =  MD(P)  -  BR(JE,P)  +  CUD(NCO.P)  (IV-42) 

where  CUD(NCO.P),  a  program  input,  is  the  instigating  user's 
possibly  new  demand  rate.  This  demand  rate  could  be  the  same  as 
before,  if  the  contingency  only  reflects  a  change  in  the  user's 
essential  priority  or  if  this  pipeline  is  not  affected  by  the 
contingency.  The  instigating  user's  demand  rate  BR(JE(P)  is  then 
3et  equal  to  its  possibly  new  value  CUD(NCO.P),  and  its  normal 
essential  priority  BIP(JE,P)  is  set  equal  to  its  possibly  new 
value  CUP(NCO,P).  If  the  user's  supply  level  is  not  in  the 
safety  region,  then  the  user's  actual  essential  priority  BP(JE,P) 
is  also  set  equal  to  CUP(NCO,P). 

If  this  is  the  last  pipeline  to  be  processed  for  this 
contingency  (IC=3),  then  the  next  contingency  to  be  processed  is 
determined.  The  contingency  event  counter  NCO  is  incremented  by 
one,  and  then  a  check  is  made  to  determine  if  there  is  another 
scheduled  contingency.  If  not  (NCO  >  NOC) ,  then  the  time  of 
occurrence  of  the  next  contingency  event  TE(NB2,IP)  is  set  equal 
to  a  large  number  for  each  pipeline  IP  (recall  that  the  index  P 
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at  this  point  refers  only  to  the  pipeline  being  processed). 
Otherwise,  a  check  is  made  to  determine  if  the  next  scheduled 
contingency  involves  an  active  user  (BIG(CUN(NCO) )  =1).  If  not, 
the  contingency  event  counter  is  incremented  by  one,  and  the 
procedure  described  immediately  above  is  repeated.  Otherwise, 
the  next  contingency  event  time  TE(NB2,IP)  for  each  pipeline  IP 
is  set  equal  to  the  time  of  occurrence  of  the  next  contingency 
TE(NCO) . 

Whether  or  not  this  is  the  last  pipeline  to  be 
processed  for  this  contingency,  the  module  processing  proceeds  in 
the  following  manner.  A  test  is  made  to  determine  if  the 
instigating  user's  demand  rate  for  this  pipeline  increased  (MD(P)  > 
MDOLD),  decreased  (MD(P) <  MDOLD),  or  remained  the  same  (MD(P)  = 
MDOLD) .  Each  of  these  cases  requires  different  processing. 

The  simplest  case  is  when  the  user's  demand  rate 
remained  the  same.  A  test  is  then  made  to  determine  if  the 
user's  normal  essential  priority  changed  (BIP(JE,P)  BPOLD).  If 
not,  then  this  contingency  does  not  affect  the  pipeline  being 
processed  and  the  module  returns  to  control  (Fig.  IV-2)  to 
determine  the  next  event  to  be  processed.  Otherwise,  the  message 
"CONTINGENCY  EVENT— USER  NUMBER  JE"  is  printed  out  on  the  Event 
Chronology  for  this  pipeline,  where  JE  denotes  the  index  of  the 
instigating  user.  Also,  the  supply  levels  are  printed  out  on  the 
Event  Sequenced  Supply  Level  table  for  this  pipeline.  If  demand 
is  being  satisfied  (SR(P)  =  MD(P)),  or  if  the  instigating  user's 
supply  level  is  in  the  safety  region  (SE(JE,P)  =  4)  so  that  its 
present  essential  priority  is  at  the  maximum  value  of  unity), 
then  this  change  in  the  normal  essential  priority  for  this  user 
will  not  affect  the  present  pipeline  operation.  Thus,  the  module 
returns  to  Control  (Section  2)  to  determine  the  next  event  to  be 
processed.  Otherwise,  this  change  in  the  normal  essential 
priority  will  affect  the  pipeline  operation  through  the 
alteration  of  the  user  supply  rates,  which  are  presently  less 
than  their  respective  demand  rates  and,  as  such,  are  dependent  on 
the  user's  essential  priorities.  The  module  then  proceeds  to 


determine  new  supply  rates  for  each  active  user  in  this  pipeline 
and  then  establishes  the  next  event  types  and  times  of  each  user 
relative  to  the  pipeline  being  processed.  These  are  done  in  the 
same  manner  as  that  described  at  the  end  of  Section  3  (Cargo 
Carrier  Processing).  The  module  then  returns  to  Control  (Section 
2)  to  determine  the  next  event  to  be  processed.  This  completes 
this  portion  of  the  Contingency  Event  Processing. 

If  the  instigating  user's  demand  rate  for  this  pipeline 
increased  due  to  this  contingency,  the  module  processing  proceeds 
in  the  following  manner.  First,  the  message  "CONTINGENCY 
EVENT — USER  NUMBER  JE"  is  printed  out  on  the  Event  Chronology  for 
this  pipeline,  and  the  supply  levels  are  printed  out  on  the  Event 
Sequenced  Supply  Level  table  for  this  pipeline.  The  next 
function  is  to  establish,  by  calling  on  Subroutine  REVISE 
(Section  11),  the  new  static  pipeline  flow  parameters:  that  is, 
the  number  of  cargo  carriers  required  to  maintain  the  static 
pipeline  operation  NC(P);  the  cargo  carrier  load  for  each  of 

these  carriers  CL(P);  and  the  separation  time  between  cargo 
carriers  TR(P).  The  module  then  checks  to  see  if  the  ISP  is 
drawing  from  its  emergency  supplies  (ESP(P)  =  1).  If  not,  the  ISP 
supply  rate  is  set  equal  to  the  new  total  demand  rate  (SR(P)  = 
MD(P) ) ,  and  the  instigating  user's  supply  rate  is  set  equal  to 
its  new  demand  rate  (BS(JE,P)).  If  the  ISP  is  drawing  from 
emergency  supplies,  then  the  next  step  is  to  determine  the 

maximum  allowable  supply  rate,  SRT,  which  is  computed  as 
indicated  previously  in  Eq.  (IV-26)  in  Section  3.  If  user 
demands  can  still  be  satisfied  (SRT  ^MD(P) ) ,  then  the  ISP  supply 
rate  is  set  equal  to  the  new  total  demand  rate,  and  the 
instigating  user's  supply  rate  is  set  equal  to  its  new  demand 

rate,  as  indicated  above.  If  user  demands  cannot  be  satisfied, 

then  the  ISP  supply  rate  is  set  equal  to  its  maximum  allowable 
value  (SR(P)  =  SRT).  The  module  then  determines  the  allowable 
user  supply  rates  and  the  next  event  times  and  types  for  each 
user  relative  to  the  pipeline  being  processed,  in  the  manner  as 
that  described  at  the  end  of  Section  3  (Cargo  Carrier 
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Processing).  For  all  the  cases  described  in  this  paragraph,  the 
module  then  prints  out  the  new  supply  rates  on  the  Supply  Rate 
Variation  table  for  this  pipeline. 

The  next  function  is  to  set  up  a  new  cargo  carrier 
arrival  schedule.  The  first  step  is  to  determine  the  time  of 
arrival,  TFA,  of  the  first  possible  newly  scheduled  cargo  carier. 
This  is  given  by  the  following  equation: 


TFA  =  CT  +  SCC(P)  • 

MSD(P) 

24.  SCS(P) 


(  — i _ 

\  SPR(P) 
+  MOT (P) 


SCL(P)  MSU(P) 


U(P)) 


(IV-43) 


The  next  step  is  to  determine  the  number  of  enroute  cargo 
carriers.  This  requires  the  determination  of  the  time  of 
arrival,  TEM,  of  a  hypothetical  cargo  carrier  that  would  be  in 
load  preparation  at  the  time  that  a  revised  supply  order  would  be 
received  at  the  supply  source.  This  is  computed  the  same  as  TFA 
above  in  Eq.  IV-43,  with  the  exception  that  SCC(P)  is  replaced  by 
CLOLD,  the  previous  static  pipeline  cargo  carrier  load.  The 
previous  cargo  carrier  arrival  DT(J,P)  is  then  compared  with  TEM. 
If  DT( J,P) <_  TEM,  then  this  Jth  cargo  carrier  will  be  identified 
as  an  interim  cargo  carrier  and  will  remain  in  the  cargo  carrier 
arrival  schedule.  The  number  of  interim  cargo  carriers  NIC(P) 
will  be  set  equal  to  the  total  number  of  such  cargo  carriers. 
Since  there  has  been  an  increase  in  demand,  these  interim  cargo 
carriers  will  not  carry  sufficient  supplies  to  meet  demand  during 
the  interim  period.  Thus  the  amount  of  expected  shortfall,  CAR, 
that  will  have  to  be  made  up  is  now  computed  in  the  following 
manner.  Let  TSA  denote  the  time  of  arrival  of  the  next  scheduled 
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non-enroute  cargo  carrier,  and  let  CLP  denote  its  cargo  load, 
that  is 


TSA  =  DT(NIC( P)+1 , P)  (IV-44) 


CLP  =  DC(MIC(P)+1,P) 


(IV-45) 


Then 


CAR  =  CLP  +  (MD-MDP)* (TSA-CT)  (IV-46) 

where  CAR  actually  includes  some  extra  shortfall  that  would 
accumulate  in  the  time  interval  from  the  time  of  arrival  of  the 
first  possible  newly  scheduled  cargo  carrier,  TFA,  to  the  time  of 
arrival  of  the  next  scheduled  non-enroute  cargo  carrier,  TSA. 
This  is  accounted  for  in  scheduling  new  interim  cargo  carriers, 
as  will  now  be  described. 

The  number  of  new  interim  cargo  carriers  required, 
denoted  for  the  present  by  the  dummy  variable  TEM,  is  computed  as 
follows: 


tt7M  =  CAR  -  MD(P)’  (TSA-TFA)  (IV-47) 

SCC(P) 

Mow  TEM  may  not  be  an  integer  variable.  Let  ITEM  be  the  smallest 
integer  equal  to  or  less  than  TEM.  Then,  this  number  of  cargo 


85 


carriers  will  be  scheduled  immediately.  Hence,  they  will  arrive 
at  the  ISP  at  time  TFA.  Thus, 


DT{NIC( P)+J , P)  =  TFA 


( IV-48) 


DC(NIC<P)+J,P)  =  SCC(P)  (IV-49) 

where  J  ranges  from  1  to  ITEM.  If  TEM  happened  to  attain  an 
integer  value,  then  no  more  interim  carriers  will  be  scheduled 
and  the  number  of  interim  carriers  NIC(P)  in  the  new  pipeline 
will  be  given  as  follows: 


NIC(P)  =  NIC(P)  +  ITEM  (IV-50) 

If  TEM  is  not  integer-valued,  then  one  more  interim  cargo  carrier 
must  be  scheduled,  but  it  will  have  a  greater  time  of  arrival 
than  TFA.  To  determine  this  time  of  arrival,  it  is  first 
required  to  determine  the  time  of  arrival,  TL,  of  the  previous 
departing  cargo  carrier.  If  ITEM  was  greater  than  zero,  then  TL 
=  TFA.  If  not,  then  TL  =  DT(NIC(P),P)  if  there  are  enroute  cargo 
carriers,  or  if  there  are  no  enroute  cargo  carriers,  then 


TL  =  CT 


MSC(P)  -  SL(P) 
MD  (P) 


(IV-51) 
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a  fictitious  time  of  arrival  of  a  previous  cargo  carrier,  at 
present  demand  rate,  that  if  fully  loaded  would  arrive  in  time 
with  the  proper  load.  At  this  point,  the  number  of  additional 
interim  cargo  carriers  ITEM  is  increased  by  one  to  account  for 
this  one  presently  being  scheduled.  That  is, 


ITEM  =  ITEM  +  1  (IV-52) 

Next,  the  required  time  of  arrival  TLA  of  this  last  interim  cargo 
carrier,  given  a  full  cargo  load,  is  determined  as  follows: 


TLA  =  TSA 


CAR-ITEM*  SCC(P) 
MD(P) 


(IV-53) 


It  is  now  required  to  check  if  the  interval  of  time  between 
arrival  of  this  last  interim  cargo  carrier  and  the  previous 
arriving  one  (TLA-TL)  is  greater  than  the  new  separation  time 
between  arrivals  TR(P)  of  cargo  carriers  in  the  static  pipeline. 
If  not,  this  last  interim  carrier  is  scheduled  to  arrive  at  time 
TLA  with  a  full  cargo  load.  That  is. 


DT(NIC(P)+ITEM,P)  =  TLA  (IV-54) 


DC(NIC(P)+ITEM, P)  =  SCC(P)  (IV-55) 


If  (TLA-TL)  is  greater  than  TR(P),  then  the  cargo  carrier  will  be 
scheduled  to  arrive  sooner  with  a  less-than-full  cargo  load,  but 


not  before  the  time  of  the  first  possible  newly  scheduled  cargo 
carrier  arrival  TFA.  Let  the  dummy  variable  TEM  be  determined  as 
follows 


TEM  =  max (TL+TR ,  TFA} 


(IV-56) 


Then  the  scheduled  time  of  arrival  and  cargo  load  of  this  last 
scheduled  interim  cargo  carrier  are  given  as  follows: 


DT(NIC(P)+ITEM,P)  =  TEM 


(IV-57) 


DC(NIC(P)+ITEM,P)  =  SCC(P)  -  MD( P)» (TLA-TEM)  (IV-58) 


The  number  of  interim  cargo  carriers  in  the  pipeline  NIC(P)  is 
now  determined  according  to  Eq.  (IV-50),  specified  previously  in 
this  section.  This  completes  the  scheduling  of  interim  cargo 
carriers  for  the  new  pipeline. 

The  next  step  is  to  schedule  the  new  static  pipeline 
cargo  carriers.  The  static  pipeline  flow  parameters  (NC(P), 
TR(P),  and  CL(P))  were  established  earlier  in  the  processing  of 
this  increase-in-deraand  case.  The  scheduled  arrival  times  and 
cargo  load3  of  these  carriers  are  given  as  follows: 


DT(NIC(P)+J,P)  =  DT(NIC(P),P)  +  J.TR(P)  (IV-59) 
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DC( NIC( P)+J , P)  =  CL( P ) 


(IV-60) 


where  J  ranges  from  1  to  NC(P)  +  1.  The  total  number  of  cargo 
carriers  NTC(P)  in  the  pipeline  is  also  determined  by  the 
following  equation: 


NTC(P)  =  NIC( P)  +  NC( P)  +  1 


( I V— 6 1 ) 


The  final  step  is  to  determine  the  next  event  type  and 
time  for  the  ISP.  If  the  ISP  is  presently  drawing  from  emergency 
supplies  (ESP(P)  =  1),  then  the  next  event  type  will  be  a  cargo 
carrier  arrival  (SE(NB1,P)  =  1),  and  the  time  of  occurrence  will 
be  the  arrival  time  of  the  next  cargo  carrier  (TE(NB1,P)  = 
DT ( 1 , P ) ) .  Otherwise,  it  must  be  determined  if  the  next  cargo 
carrier  will  arrive  before  the  ISP  would  have  to  begin  drawing 
from  its  emergency  supplies.  Let  TEM  denote  this  time,  than 


TEM  =  CT  + 


SL(P)-MES (P) 
MD(P) 


( IV-62) 


If  TEM  is  greater  or  equal  to  the  time  of  arrival  of 
the  next  cargo  carrier,  then  the  next  ISP  event  will  be  the 
arrival  of  the  cargo  carrier  (SE(NB1,P)  =  1  and  TE(NB1,P)  = 
DT(1,J)).  Otherwise,  the  next  event  will  be  the  ISP  drawing  from 
its  emergency  supplies  (SE(NB1,P)  =  2  and  TE(NB1,P)  =  TEM). 

At  this  point,  the  module  returns  to  Control  (Section 


2)  to  determine  the  next  event  to  be  processed.  This  completes 
this  portion  of  the  Contingency  Event  Processing. 

If  the  instigating  user’s  demand  rate  for  this  pipeline 
decreased  due  to  this  contingency,  the  module  processing  proceeds 
in  the  following  manner.  First,  the  message  "CONTINGENCY 
EVENT— USER  NUMBER  JE"  is  printed  out  on  the  Event  Chronology  for 
this  pipeline.  At  this  point,  the  processing  of  a  user 
withdrawal  for  the  non-instigating  pipeline  parallels  the 
Contingency  Event  processing.  Here,  the  User  Withdrawal 
Processing  (Section  6)  is  transferred  to  this  processing  section 
of  the  module.  The  module  next  prints  out  the  supply  levels  on 
the  Event  Sequenced  Supply  Level  table  for  this  pipeline. 

If  the  ISP  is  not  drawing  from  its  emergency  supplies 
(ESP(P)  =  0),  then  the  ISP  supply  rate  SR(P)  is  set  equal  to  the 
new  total  demand  rate  MD(P),  and  the  instigating  user's  supply 
rate  BS(JE,P)  is  set  equal  to  its  new  demand  rate  BR(JE,  P).  The 
new  supply  rates  are  then  printed  out  on  the  Supply  Rate 
Variation  table  for  this  pipeline. 

If  the  ISP  is  presently  drawing  from  its  emergency 
supplies,  then  the  first  step  is  to  determine  its  maximum 
allowable  supply  rate  SRT  as  follows: 


SRT  = 


SL (P)  -  MCS(P) 
DT (1 ,P)  -  CT 


(IV-63) 


If  total  demand  cannot  be  satisfied  (SRT<MD(P)),  then  the  ISP 
supply  rate  is  set  equal  to  the  maximum  allowable  supply  rate 
(SR(P)  =  SRT).  The  allowable  user  rates  and  the  next  event  times 
and  types  for  each  user  relative  to  this  pipeline  are  then 
determined  in  the  manner  described  at  the  end  of  Section  3  (Cargo 
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Carrier  Arrival  Processing). 

If  total  demand  can  be  satisfied,  the  ISP  supply  rate 
is  set  equal  to  the  total  demand  rate  (SR(P)  =  MD(P)),  and  the 
user  supply  rates  are  set  equal  to  their  demand  rates  (BS(I,P)  = 
BR ( I , P) ) .  Also,  the  users'  next  event  times  TE(I,P)  are  all  set 
equal  to  a  large  number.  With  a  decrease  in  demand,  a  supply 
surplus  may  be  accumulated  before  the  arrival  of  the  next  cargo 
carrier.  If  this  is  the  case  (SRT  >MD(P)),  then  the  amount  of 
supply  surplus  SFM  is  determined  by  the  following  equation: 


SFM  =  (SRT-MD(P) )  •  (DT(1,P)-CT) 


(IV-64) 


This  supply  surplus  is  then  distributed  to  the  active  users,  in 
accordance  with  the  procedures  described  in  Subroutine  SHTFAL 
(Section  14).  Because  user  supply  levels  have  changed,  these  new 
supply  levels  are  printed  out  on  the  Event  Sequenced  Supply  Level 
table  for  this  pipeline. 

In  the  above  cases  where  the  ISP  was  previously  drawing 
from  its  emergency  supplies,  at  least  one  user  supply  rate  has 
changed.  Thus,  the  ISP  and  user  supply  rates  are  printed  out  on 
the  Supply  Rate  Variation  table  for  this  pipeline. 

For  all  decrease-in-demand  cases,  the  next  function  is 
to  set  up  a  new  cargo  carrier  arrival  schedule.  The  first  step 
is  to  determine  the  arrival  time,  TEM,  of  a  cargo  carrier  that 
would  be  in  load  preparation  when  the  new  supply  order  revision 
is  received  at  the  supply  source.  This  is  determined  by  the 
following  equation: 
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TEM  =  CT  +  CLOLD  • 


MSD(P) 


24  .  SCS(P) 


\  SPR(P)  SCL(P)  MSU(P), 
+  MOT ( P ) 


( IV-65) 


Next,  the  number  of  enroute  carriers  is  determined.  If  DT(J,P) 
TEM,  then  this  Jth  cargo  carrier  will  be  identified  as  an  interim 
cargo  carrier  and  will  remain  in  the  cargo  carrier  arrival 
schedule.  The  number  of  interim  cargo  carriers  NIC(P)  will  be 
set  equal  to  the  total  number  of  such  cargo  carriers.  Because 
there  has  been  a  decrease  in  demand,  these  cargo  carriers  will  be 
carrying  an  excess  of  supplies,  but  it  would  be  inefficient  to 
change  their  already  implemented  schedule.  However,  for  the  next 
scheduled  cargo  carrier,  this  can  be  accomplished.  First,  the 
amount  of  overfall  SOF  that  the  cargo  carrier  would  be  carrying 
is  determined  in  the  following  manner.  Its  present  scheduled 
time  of  arrival,  TN,  and  its  cargo  load,  CLI,  are  given  as 
follows: 


TN  =  DT(NIC( P)+1 , P)  (IV-66) 


CLI  =  DT(NIC(P)+1 ,P)  (IV-67) 

Also  required  is  the  time  of  arrival,  TL,  of  the  last  interim 
carrier  now  scheduled.  If  there  are  no  scheduled  Interim 
carriers,  then  this  time  of  arrival  is  set  equal  to  the  current 
time  for  this  computation.  Thus, 
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DT (NIC(P) ,P) 
CT 


if  NIC(P)  *  0  \ 
if  NIC (P)  =0  x 


(IV-68) 

\ 


\ 

For  subsequent  computations,  in  the  case  where  there  are  no 
interim  cargo  carriers,  the  variable  TL  is  reset  to  \he 
following: 


TL  *  CT  - 


MSC(P)  -  SL(P) 
MD(P) 


( IV-69) 


Also,  at  this  point,  the  number  of  intriro  carriers  is  increased 
by  one  (NIC(P)+1).  The  projected  supply  overfall,  SOF,  is  then 
determined  by  the  following  equation: 


SOF  =  (MDOLD  -  MD(P))*(TN-TL)  (IV-70) 


The  scheduled  arrival  of  this  cargo  carrier  may  be  extended  to 
the  time  TPA,  where 


TPA 


_  .  SOF  +  SCC(P)  -  CLI 

TN  + - ~lrnm - 


( IV-71) 


This  will  be  the  case  if  the  time  interval  between  arrival  of 
this  last  interim  cargo  carrier  and  the  previous  arriving  one 
(TPA-TL)  is  less  than  or  equal  to  the  new  separation  time  between 
arrivals  TR(P)  of  cargo  carriers  in  the  static  pipeline.  If  so, 
this  last  Interim  cargo  carrier  is  scheduled  to  arrive  at  time 
TPA  with  a  full  cargo  load.  That  is. 


DT(NIC(P),P)  =  TPA 


(IV-72) 


DC(NIC(P),P)  =  SCC(P) 


(IV-73) 


If  (TPA-TL)  is  greater  than  TR(P),  then  the  scheduled  arrival 
time  must  be  decreased,  accompanied  by  a  decrease  in  cargo  load. 
To  accomplish  this,  the  time  of  first  possible  arrival,  TFA, 
which  will  bring  the  ISP  supply  level  to  its  maximum,  is  first 
determined.  Now  the  cargo  load  will  itself  be  a  function  of  TFA, 
that  is, 


CLI  =  SCC(P)  -  (TPA-TFA)* MD(P)  (IV-74) 


Substituting  this  in  the  normal  equation  for  the  time  of  arrival 
(i.e.,  see  Eq.  IV-65)  results  in  the  following  equation: 


FA  *  CT  +  (SCC(P)  -  (TPA-TFA)*  MD(P))* 


SPR(P)  SCL(P)  MSU (P) , 


+ 


MSD(P) 

24 •  SCS(P) 


+  MOT  (P) 
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( IV-75) 


Solving  this  for  TFA  results  in  the  following  solution: 


TFA 


CT+  (SCC(P)-TPA  •  MD(P)  )• 


(_i 

\SPR 


MSD(P) 

SPR(P)  '  SCL(P)  '  MSU(P)/  24  *  SCS ( P ) 


U(P) ) 


+  MOT ( P ) 


1  -  MD(P) 


i  SPR(P)  SCL(P)  MSU(P) 


U(P)) 


(1V-76) 


The  interval  between  arrivals  must  now  be  checked.  If  (TFA-TL)  is 
greater  than  TR(P),  then  the  TR(P)  time  requirement  between 
arrivals  cannot  be  satisfied.  Thus,  TFA,  representing  the 
arrival  time  of  the  first  possible  newly  scheduled  cargo  carrier, 
will  be  the  scheduled  arrival  time  of  the  last  interim  carrier. 
In  this  case, 


DT(NIC(P),P)  =  TFA  ( IV-77) 


DC(NIC(P),P)  =  CLI  (IV-78) 


On  the  other  hand,  if  (TFA-TL)  is  less  than  TR(P),  then  the 
scheduled  arrival  can  be  extended  so  that  the  time  interval 
between  arrivals  equals  TR(P).  Thus, 


-  -  n  liM— Ulttiriiri  r  " 
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DT(NIC(P),P)  =  TL  +  TR( P) 


(IV-79) 


DC(MIC(P),P)  =  SCC(P)  -  (TPA-TR(P)-TL)»MD(P)  (IV-80) 


This  completes  the  scheduling  of  interim  cargo  carriers  for  the 
new  pipeline. 

The  next  step  is  to  schedule  the  new  static  pipeline 
carriers,  determine  the  total  number  of  cargo  carriers  in  the 
pipeline,  and  determine  the  next  event  time  and  type  for  the  ISP. 
This  is  done  in  the  manner  previously  descriibed  in  this  section 
(see  discussion  surrounding  Eq.  (IV-59)  to  IV-62)). 

The  final  step  is  to  determine  the  proper  return  point 
in  the  module.  If  the  event  being  processed  is  a  User  Withdrawal 
Event  (IW=1),  then  the  module  returns  to  the  end  of  the  User 
Withdrawal  Processing  (Section  6)  to  determine  if  there  is 
another  pipeline  to  be  processed.  Otherwise  (IW=0),  the  event 
being  processed  is  a  Contingency  Event,  and  the  module  returns  to 
Control  (Section  2)  to  determine  the  next  event  to  be  processed. 

8.  Routine  Printout  Processing  (Fig.  IV-8) 

The  first  step  is  to  determine  the  time  TEM  for  the 
next  scheduled  printout.  This  is  given  as  follows: 

TEM  =  CT+TP  (IV-81) 

where  TP  is  the  input-specified  printout  interval.  If  this  time 
is  less  than  the  scheduled  run  duration  TDUR,  then  the  time  of 
the  next  scheduled  printout  is  set  equal  to  TEM.  That  is, 

TE(NB3.P>  =  TEM  (IV-82) 

Because  the  scheduled  event  type  is  already  a  Scheduled  Printout 
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FIGURE  1V-8  LOGIC  FLOWCHART  (ROUTINE  PRINTOUT  PROCESSING) 
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Event  (SE(NB3,P)  =  6),  this  variable  ne^d  not  be  changed.  On  the 
other  hand  (TDUR  <_  TEM) ,  the  next  scheduled  event  will  be  a  Run 
Termination  Event  that  will  occur  at  time  TDUR.  Thus, 

TE(NB3,P)  =  TDUR  (IV-83) 

SE(NB3,P)  =  7  (IV-84) 

Once  the  next  scheduled  event  time  and  type  have  been 
established,  the  module  prints  out  the  supply  levels  on  the  Time 
Sequenced  Supply  Level  table  for  this  pipeline.  The  module  then 
returns  to  Control  to  determine  the  next  event  to  be  processed. 

9.  Scheduled  Run  Termination  Processing  (Fig.  IV-9) 

When  a  Run  Termination  Event  occurs,  the  supply  levels 
for  the  pipeline  whose  event  was  chosen  will  already  have  been 
determined  in  Control  processing  and  printed  out  on  the  Event 
Sequenced  Supply  Level  table  for  that  pipeline.  The  supply 
levels  for  the  other  pipelines  are  now  determined  in  accordance 
with  Eq.  (IV-13)  and  (IV-14)  of  Section  2,  and  they  are  printed 
out  on  their  respective  Event  Sequenced  Supply  Level  table.  The 
module  then  prints  out  the  message  "RUN  TERMINATED  BEFORE  LAST 
CONTINGENCY  HAS  BEEN  STABILIZED"  on  the  Event  Chronologies  of 
each  pipeline.  In  addition,  the  supply  levels  and  supply  rates 
are  respectively  printed  out  on  the  time  Sequenced  Supply  Level 
Table  and  Supply  Variation  table  for  each  pipeline.  The  module 
then  proceeds  to  Output  Processing  (Section  10). 

10.  Output  Processing  (Fig.  IV-10) 

The  output  tables  for  each  pipeline  are  stored  on 
separate  internal  files.  In  Output  Processing,  the  module  copies 
these  Internal  files,  in  sequential  order  for  each  pipeline,  onto 
the  final  output  file,  which  is  then  printed  out  on  a  line 
printer.  This  completes  a  module  run. 
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FIGURE  IV-9  LOGIC  FLOWCHART  (SCHEDULED  RUN  TERMINATION  PROCESSING) 
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11.  Subroutine  REVISE  (Fig.  IV-11) 

This  subroutine  is  called  at  several  points  throughout 
the  mam  module  when  the  demand  on  the  ISP  is  altered.  Its 
purpose  is  to  establish  static  pipeline  flow  parameters  that  will 
satisfy  this  new  demand.  The  flow  parameters  are:  NC(P),  the 
number  of  cargo  carriers  required  to  maintain  the  static  pipeline 
operation;  CL(P),  the  cargo  carrier  load;  and  TR(P),  the 
separation  time  between  cargo  carriers. 

The  first  step  in  establishing  these  pipeline  flow 
parameters  is  to  determine  the  maximum  allowable 
time-between-arrivals  TCM  for  cargo  carriers  so  that  the  ISP 
would  not  have  to  draw  from  its  emergency  supplies  during  static 
pipeline  operations.  This  is  computed  by  the  following  equation: 


MSC(P)  -  MES(P)  (IV-85) 

where  MSC(P)  is  the  ISP’s  storage  capacity,  MES(P)  is  its 
emergency  supply  level,  and  MD(P)  is  the  total  demand  rate  on  the 
ISP.  The  next  step  is  to  determine  the  number  of  supply  days, 
TEM,  that  could  be  provided  by  one  cargo  carrier  with  a  full 
load.  This  is  given  by 


TEM 


SCC(P) 

MD(P) 


( IV-86) 


where  SCC(P)  is  the  cargo  carrier  capacity. 

If  this  number  of  supply  days  is  less  than  or  equal  to 
the  maximum  allowable  time-between-arrivals  (TEM  <_  TCM) ,  then 
cargo  carriers  with  full  loads  will  be  scheduled  for  the  pipeline 
operation.  Thus, 
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TR(P)  =  TEM 


( IV-87) 


CL(P)  =  SCC(P)  ( IV-88) 

TCP  =  TCY  (IV-89) 

where  TCP  denotes  the  cargo  carrier  cycle  time  and  TCY  is-  a  cargo 
carrier's  maximum  cycle  time,  computed  in  the  module 
Initialization  (see  Eq.  (IV-5)  of  Section  1).  TCP  is  required 
below  in  determining  the  number  of  cargo  carriers  required  to 
maintain  the  static  pipeline  operation. 

If  the  number  of  supply  days  provided  by  a  fully-loaded 
cargo  carrier  exceeds  the  maximum  allowable  time-between-arrivals 
(TEM  >  TCM) ,  then  cargo  carriers  with  reduced  loads  will  be 
required  for  the  pipeline.  Thus, 

TR(P)  =  TCM  (IV-90) 

CUP)  =  TR(P)  •  MD(P)  (IV-91) 


TCP  -  TCY  -  (SCC(P)  -  CL(P) )  .  ( ^  +  +  5^) 

(IV-92) 

when  SPR(P)  is  the  cargo  preparation  rate,  SCL(P)  is  the  cargo 
loading  rate  at  the  supply  source,  and  MSU(P)  is  the  cargo 
unloading  rate  at  the  ISP. 

The  number  of  cargo  carriers  NC(P)  requiried  to 
maintain  the  pipeline  is  then  determined  as  follows: 

NC<P>  ■  Wm  uv-,3) 
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If  this  number  is  not  an  integer  value,  then  one  additional  cargo 
carrier  must  be  added  to  the  pipeline.  That  is, 


NC(P)  =  NC(P)  +  1  (IV-94) 

The  subroutine  processing  is  now  complete,  and  a  return  is  made 
to  the  main  module  at  the  subroutine  calling  point. 

12.  Subroutine  NEXTEV  (Fig.  IV-12) 

This  subroutine  is  called  upon  at  several  points  in  the 
main  module  when  user  supply  rates  change  and  the  ISP  cannot  meet 
the  total  demand.  Its  purpose  is  to  establish  the  next  event 
time  and  types  for  each  active  user  in  the  pipeline.  The  index  I 
denotes  the  user  number,  and  it  is  initially  set  equal  to  one. 

If  the  user  being  processed  is  no  longer  active  (3IG(I) 
=  0),  then  processing  proceeds  to  the  end  of  the  subroutine, 
where  a  check  is  made  to  see  if  there  are  any  more  users  to  be 
processed .  If  the  user  is  active  (BIG(I)  =  1),  then  a  check  is 
made  to  see  if  the  user's  supply  level  is  in  its  safety  region, 
which  holds  true  if  the  user's  next  event  is  a  User  Withdrawal 
Event  (SE(I,P)  =4).  If  such  is  the  case,  then  the  revised  time 
TE(I,P)  for  this  event  to  occur  is  determined  by  the  following 
equation: 


TE(I,P)  =  CT  + 


BL(I,P)  -  BCL(I.P) 
BR(I,P)  -  BS (I ,P) 


( IV-95) 


where  BL(I,P)  denotes  the  user's  supply  level,  BCL(I,P)  denotes 
the  user's  critical  supply  level,  BR(I,P)  denotes  the  user's 
demand  rate,  and  BS(I,P)  denotes  the  user's  supply  rate. 
Otherwise,  the  user's  next  event  will  be  the  user's  supply  level 
dropping  below  its  safety  level,  so  that  the  next  event  indicator 
SE(I,P)  is  set  equal  to  three.  The  time  of  occurrence  for  this 
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event  is  determined  as  follows: 


TE(I,P)  =  CT  + 


BL(I,P)  -  BSL(I,P) 
BR(I,P)  -  BS (I ,P) 


(IV-96) 


This  completes  the  processing  for  this  user.  If  there 
is  another  user,  the  user  number  index  I  is  incremented  above  and 
the  subroutine  processing  for  this  user  follows  that  described 
above.  If  there  are  no  more  users  to  be  processed,  then  the 
subroutine  processing  is  complete,  and  a  return  is  made  to  the 
main  module  at  the  subroutine  calling  point. 

13.  Subroutine  ALLOC  (Fig.  IV-13) 

This  subroutine  is  called  upon  at  several  points 
throughout  the  main  module  when  the  ISP  cannot  meet  the  total 
demands.  The  purpose  of  this  subroutine  is  to  determine 
weighting  factors  WB(I)  that  determine  the  amount  of  expected 
shortfall  to  be  allocated  to  each  user.  The  allocation  scheme 
used  is  based  on  the  premise  that  the  shortfall  allocated  to  a 
user  should  be  directly  proportional  to  its  demand  rate  BR(I,P), 
but  inversely  proportional  to  its  essential  priority  (BP(I,P). 
Let  SF(I)  denote  the  Ith  user's  allocated  shortfall,  then  this  is 
accomplished  if 


SF(I)  =  K  .  fl^fy  (IV-97) 


for  all  I  users,  where  K  is  an  unknown  constant.  The  weighting 
factor  WB(I)  to  determine  for  each  user  is  such  that 

SF(I)  =  WB( I) •  TSF 
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(IV-98) 


FIGURE  IV-13  LOGIC  FLOWCHART  (SUBROUTINE  ALLOC) 
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where  TSF  is  the  total  expected  shortfall.  Substituting  this  in 
Eq.  (IV-97)  and  letting  K'  =  K/TSF  results  in  the  following  set 
of  equations: 


■ K’  *  §o^)  (IV-9?> 


for  I  =  1,  ...  ,  NB,  where  NB  is  the  number  of  users.  Thus,  we 
have  NB  equations  with  (NB+1)  unknowns  (the  WB(I)  and  K').  But 
we  must  have  the  following  condition  satisfied: 

NB 

wb(i)  =  1  (iv-ioo) 

1=1 


Hence,  we  have  (NB+1)  equations  with  (NB+1)  unknowns.  The 
solution  to  this  set  of  equations,  neglecting  the  unrequired 
constant  K' ,  is  given  by  the  following  set  of  equations,  one  for 
each  1=1 ,  ....  NB: 


n  A(J) 

J#I 

WB(I)  =  -  (IV— 101 ) 

NB 

i  ru(j) 

1=1  J*K 


where  A(J)  =  BP( J,P)/BR( J,P) . 

The  above  representation  assumes  that  all  users  are 
active.  In  the  actual  processing,  inactive  users  are  not 
considered  30  that  the  sums  and  products  are  taken  over  only  the 
active  users.  For  inactive  users,  WB(I)  is  automatically  equal 
to  zero. 

This  computation  of  the  above  WB(I)  factors  is  made  in 
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this  subroutine,  and  then  a  return  is  made  to  the  main  module  at 
the  subroutine  calling  point. 

14.  Subroutine  SHTFAL  (Fig.  IV-14) 

This  subroutine  is  called  on  at  several  points  in  the 
main  program  when  there  are  user  shortfalls  and  the  ISP  has,  or 
can  expect,  a  supply  surplus  before  the  arrival  of  the  next  cargo 
carrier.  That  is,  its  supply  level  would  be  greater  than  its 
critical  supply  level  when  the  next  cargo  carrier  is  scheduled  to 
arrive.  The  purpose  of  this  subroutine  is  to  distribute  this 
supply  surplus  to  the  users,  taking  into  account  the  criticality 
of  each  user’s  shortfall. 

The  subroutine  first  determines  if  there  are  any  active 
users  whose  supply  levels  are  below  their  respective  safety 
levels,  which  holds  true  if  a  user's  next  event  is  a  User 
Withdrawal  Event  (SE(I,P)  =4).  If  this  is  the  case,  then  the 
surplus  is  first  distributed  to  these  users  to  bring  their  supply 
levels  up  to  their  safety  levels  (if  possible).  First,  the 
safety  region  shortfall  SF(I)  for  each  user,  relative  to  the 
pipeline  being  processed,  is  determined  by  the  following 
equation: 

(  BSL(I,P)  -  BL(I,P)  if  SE(I,P)  =  4 

SF(I)=<  (IV-102) 

(  0.  if  SE(I,P)  i»  4 

The  total  safety  region  shortfall  is  then  given  by 


NB  ■ 

SSF  =  SF(1)  ( IV— 1 03) 

1=1 ' 

Next,  it  is  determined  whether  the  supply  surplus,  denoted  by 
SFM,  is  sufficient  to  eliminate  all  the  safety  region  shortfalls 
(SFM  ^SSF) .  If  this  does  not  hold,  then  the  total  surplus  is 
proportionately  distributed  to  these  users,  and  their  new  supply 
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FIGURE  IV-14  LOGIC  FLOWCHART  (SUBROUTINE  SHORTFALL) 
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levels  are  determined  in  accordance  with  the  following  equation: 


BL(I,P)  =  BL ( I , P )  + 


SF  ( I) 
SSF 


•  SFM 


(IV-104) 


In  this  case,  the  subroutine  processing  is  completed,  and  a 
return  is  made  to  the  main  module  at  the  subroutine  calling 
point.  If,  on  the  other  hand,  (SFM  _>SSF),  then  all  the  safety 
level  shortfalls  are  made  up.  That  is, 

BL(I,P)  =  BSL(I,P)  (IV-105) 

for  all  users  with  SE(I,P)  =  4,  and  any  remaining  surplus  to  be 
distributed  is  determined  as  follows: 

SFM  =  SFM-SSF  (IV-106) 

If  this  remaining  surplus  should  equal  zero,  then  the  subroutine 
processing  is  completed,  and  a  return  is  made  to  the  main  module 
at  the  subroutine  calling  point.  Otherwise,  the  processing 
continues  as  if  there  were  initially  no  users  with  supply  levels 
in  the  safety  reg  on  but  with  the  reduced  amount  of  surplus  as 
determined  by  Eq.  (IV-106)  above. 

When  there  are  no  active  users  with  supply  levels  in 
their  respective  safety  regions,  the  first  step  is  to  determine 
each  active  user's  shortfall  as  follows: 


SF( I)  =  BML(I, P)-BL(I,P)  (IV-107) 


The  total  shortfall  SSF  is  then  given  by 


NB 

SSF  -  ^  SF(I) 
1=1 


( I V— 1 08 ) 
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where  the  sum  is,  of  course,  taken  over  only  the  active  users. 
If  the  supply  surplus  is  enough  to  eliminate  all  active  user 
shortfalls  (SFM  >  SSF) ,  then  the  active  user's  supply  levels  are 
set  equal  to  their  maximum  supply  levels.  That  is, 

BL ( I , P )  =  BML(I.P)  (IV-109) 

for  each  active  user.  Otherwise,  the  supply  surplus  is 
distributed  proportionately  among  the  active  users  in  accordance 
with  Eq.  (IV-104).  This  completes  the  processing  of  this 
subroutine,  and  a  return  is  made  to  the  main  module  at  the 
subroutine  calling  point. 

C.  Sample  Problem 

The  sample  problem  presented  in  this  section  was  designed  to 
illustrate  the  application  of  the  SUPPLY  DISTRIBUTION  MODULE  to 
the  evaluation  of  a  possible  supply  pipeline  operation.  The 
numerical  values  of  the  input  data  are,  in  general,  realistic  in 
terms  of  present  Navy  operations.  However,  some  leeway  has  been 
taken  to  allow  specific  module  events  to  occur.  The  following 
discussion  considers  the  scenario  description,  the  associated 
input  data  presentation,  and  a  description  of  the  resulting 
module  output  data.  * 

1 .  Scenario 

The  scenario  assumed  for  the  sample  problem  considers 
two  Navy  task  groups  deployed  in  the  Indian  Ocean  Basin.  Task 
Group  One  (User  No.  1)  could  represent  an  attack  carrier  task 
group,  and  Task  Group  Two  (User  No.  2)  could  represent  an 


*  The  running  of  this  sample  problem  on  a  CDC  CYBER  Series 
computer  consumed  14.3  CPU  seconds. 
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amphibious  task  group,  deployed  at  some  distance  from  the  carrier 
task  group.  These  two  task  groups  are  supplied  by  a  sea-based 
service  group,  which  could  consist  of  a  stores  ship  (AF),  an 
oiler  (AO),  and  an  ammunition  ship  (AE). 

The  service  group  is  replenished  by  MSG  or  commercial 
ships  sailing  from  alternative  supply  sources.  The  supply  of 
bulk  POL  is  assumed  to  emanate  from  a  relatively  close  source, 
such  as  Diego  Garcia,  which  is  located  approximately  800  nmi  from 
the  service  group.  Ammunition,  on  the  other  hand,  is  assumed  to 
be  supplied  from  a  remote  Navy  base,  such  as  Subic  Bay  in  the 

Phillipines,  located  at  a  distance  of  some  4000  nmi.  The 

remainder  of  supplies  are  obtained  from  a  port  on  the  Persian 
Gulf,  such  as  Bahrain  off  the  coast  of  Arabia,  located  at  a 
distance  of  approximately  1000  nmi. 

At  the  onset,  the  task  groups  and  the  service  group  are 
assumed  to  be  stocked  at  their  maximum  supply  capacity  levels  and 
operating  under  normal  peacetime  conditions.  On  the  85th  day  of 
deployment,  tensions  mount  in  the  area,  and  the  carrier  task 
group  is  forced  to  increase  the  tempo  of  its  operations.  At  the 
160th  day,  the  situation  has  worsened  to  such  an  extent  that 
Marines  are  sent  ashore  from  the  amphibious  task  group,  although 
there  is  no  immediate  hostile  action.  However,  15  days  later 

(Day  I/'S),  the  Marine  forces  become  engaged  in  combat  operations 
ashore.  After  five  days  of  combat,  it  is  assumed  that  the  Air 
Force  has  established  itself  in  the  area,  easing  the  burden  on 
the  carrier  task  group.  The  carrier  task  group,  in  turn,  resorts 
back  to  operations  commensurate  with  its  peacetime  operations. 
After  290  days,  combat  operations  cease,  although  the  Marine 
forces  remain  ashore.  One  month  later  (Day  320),  the  Marine 

forces  withdraw  to  their  sea-based  quarters,  but  they  remain  in 
the  area  until  Day  400.  At  that  time,  the  two  task  groups  and 
the  service  group  withdraw  from  the  :irea . 

2.  Problem  Input 

The  input  data  for  the  SUPPLY  DISTRIBUTION  MODULE 
representing  this  scenario  are  presented  in  Table  IV-2  and  IV-3. 
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Table  IV- 2 


SAMPLE  PROBLEM  INPUTS 
(Initial  Conditions) 


Input  Descriptor 

Pipeline  1 

Pipeline  2 

Pipeline  3 

Scheduled  Printout  Inputs 

Printout  interval 

30  days 

30  days 

30  days 

Scheduled  run  duration 

400  days 

400  days 

400  days 

Supply  Source  Inputs 

Pipeline  name 

BULK  POL 

AMMUNITION 

OTHER  SUPPLIES 

Cargo  carrier  capacity 

160  kbbl 

3400  ST 

4500  ST 

Cargo  carrier  speed 

20  knots 

20  knots 

20  knots 

Cargo  carrier  loading  rate 

450  kbbl/day 

4000  ST/day 

4000  ST/day 

Cargo  preparation  rate 

5000  kbbl/day 

2000  ST/day 

2000  ST/day 

Recycle  down  time 

20  days 

20  days 

20  days 

ISP  Irjpyts 

Storage  capacity 

100  kbbl 

2500  ST 

2000  ST 

Cargo  carrier  unloading  race 

380  kbbl/day 

3000  ST/day 

2800  ST/day 

Cbn  supply  demand  race 

1  kbbl/day 

0.1  ST/day 

3  ST/day 

Emergency  scores  level 

40  kbbl 

1500  ST 

1500  ST 

Critical  stores  level 

15  kbbl 

10  ST 

100  ST 

Transit  distance  between  supply 
source  and  ISP 

800  nmi 

4000  nmi 

1000  nmi 

Order  time 

2  days 

2  days 

2  days 

Number  of  Users 

2 

2 

2 

User  1  Inputs 

Initial  demand  rate 

3  kbbl/day 

2  ST/day 

25  ST/day 

Initial  essentiality  priority 
numbe  r 

0.5 

0.5 

0.5 

Maximum  supply  level 

80  kbbl 

100  ST 

1500  ST 

Safety  supply  level 

50  kbbl 

60  ST 

7  50  ST 

Critical  supply  level 

30  kbbl 

20  ST 

250  ST 

User  2  inputs 

Initial  demand  rate 

2.5  kbbl/day 

3  ST/day 

20  ST/day 

Initial  essentiality  priority 
number 

0.5 

0.5 

0.5 

Maximum  supply  level 

90  kbbl 

150  ST 

1200  ST 

Safety  aupply  level 

40  kbbl 

90  ST 

6 00  ST 

Critical  supply  level 

25  kbbl 

30  ST 

200  ST 

ST  -  Short  Tons 

kbbl  -  Thousands  of  Barrels 
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Table  IV-2  presents  the  input  data  defining  the  appropriate 
supply  characteristics  of  the  problem  components  (geography, 
supply  source,  cargo  carriers,  ISP,  and  users)  and  the  initial 
user  demand  rates  and  essential  priorities.  Table  IV-3  presents 
a  schedule  of  the  contingency  events,  indicating  the  effects  on 
the  user  demand  rates  and  essential  priorities.  These  inputs  are 
purely  hypothetical  in  nature  and  in  no  way  reflect  present  Navy 
planning  factors.  Their  use  is  intended  only  to  illustrate  the 
use  of  the  module  in  evaluating  pipeline  throughput 
distributions. 

3.  Problem  Output 

For  the  sample  scenario,  the  most  critical  pipeline  is 
the  one  servicing  Bulk  POL,  where  both  users  are  required  to  draw 
from  their  safety  region  supplies  shortly  after  the  Marine  Corp3 
forces  become  engaged  in  combat  on  Day  175.  The  other  two 
pipelines  (Ammunition  and  Other  Supplies)  are  stressed  somewhat, 
but  never  to  a  degree  that  the  user  demands  cannot  be  satisfied. 
That  is,  the  ISP  does  have  to  draw  from  its  emergency  supplies 
for  short  time  periods  for  each  of  these  two  pipelines.  However, 
this  is  never  done  to  the  extent  that  user  demands  cannot  be 
satisfied. 

In  the  case  of  Bulk  POL,  the  situation  is  more 
critical.  Fig.  IV-15  provides  a  graphical  representation  of  the 
ISP  and  user  supply  levels  for  Bulk  POL  during  a  35-day  period 
encompassing  Day  175.  Figs.  IV-16  and  IV-17  present  excerpts  of 
the  Event  Chronology  and  Event  Sequenced  Supply  Level  tables  for 
this  pipeline  during  this  period.  Figs.  IV— 1 8  and  IV-19 
respectively,  portray  the  complete  Time  Sequenced  Supply  Level 
table  and  Supply  Rate  Variation  table  for  Bulk  POL.  A  complete 
listing  of  the  module  output  tables  is  presented  in  Fig.  IV-20  at 
the  end  of  this  chapter  (following  Section  D.). 

Initially,  the  Bulk  POL  pipeline  has  cargo  carriers 
arriving  at  the  ISP  every  9.23  days,  transferring  60,000  barrels 
of  fuel  on  each  arrival.  This  cycle  continues  until  the  85th 
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Supply  Level  {kbbl)  Supply  Level  (kbbl)  Supply  Level  (kbbl) 


TABLE  1  PIPELINE  -  BULb  POL 
EVENT  CHRONOLOGY 

EVK  .T 
TYPE 

T IMP  K ij m r* E K  EVENT  TESCRIPTIfN 


l bO , 8  7 
1  b3.66 
lb6.4b 
1S9.24 
160. (>o 
161.61 
lo2.'Ji 
163. 5b 
164.4b 
166. b4 
168.61 
170.6b 
172.7b 
174. 62 
17S.no 
175.V3 
17  6,89 
1 77. 4« 
r;».s9 

178.71 
178.96 
179.23 
1 79.6b 
180,06 
1 bO . b  / 
181.6V 

162.71 
163.73 
1 6b. 09 
1  «6 . 4  b 
187.82 


1  CAnGC  CARRIER  ARRIVAL  AT  ISP 

1  v Ahviu  CARRIER  ARRIVAL  AT  ISP 

1  CARGO  CARRIER  ARRIVAL  AT  ISP 

1  CARGO  CARRIER  ARRIVAL  AT  ISP 

b  CONTINGENCY  tVfcM  --  USER  NUMBER  2 

2  ISP  DIPPING  I^TQ  EMERGENCY  SUPPLIES 

1  cAkGO  CARRIER  ARRIVAL  AT  ISP 

2  ash  DIPPING  INTO  emergency  SUPPLIES 

1  CAnGl  carrier  arrival  at  ISP 

1  CARGO  CARRIER  ARRIVAL  AT  ISP 

1  CAkGO  CARRIER  ARRIVAL  AT  ISP 

1  CAM  GO  CARRIE*  ARRIVAL  AT  ISP 

1  CARGO  CARKIth  ARkIVAL  AT  ISP 

1  CARGO  CARRIER  ARRIVAL  AI  ISP 

b  CONTINGENCY  EVENT  ••  USER  NUMBER  2 

2  iSH  UIPPIUG  INTO  F^'ERGtNCY  SUPPLIES 

1  CAnGii  CARRIER  ARRIVAL  AT  ISP 

2  ASP  DIPPING  INTO  EMERGr.IVCY  SUPPLIES 

3  SUPPLY  LEVEL  DROPS  BELU*  SAFETY  LEVEL  —  USER 

3  SUPPLY  LEVEL  DROPS  BEcO*  SAFETY  LEVhL  --  USfcK 

1  CAitGO  carrier  arrival  at  ISP 

l  ASh  DIPPING  INTO  EMERGENCY  SUPPLIES 
1  CARGO  CARRIER  ARRIVAL  Al  ISP 
5  CONTINGENCY  EVENT  --  USER  NUMBER  1 

1  CAnGO  CARRIER  ARRIVAL  AT  ISP 

1  CAkGG  CARRIER  ARRIVAL  AT  ISP 

1  CARGO  CARRIER  ARRIVAL  AT  ISP  -V 

1  CAkGO  CARRIER  ARRIVAL  AT  ISP 

1  CARGO  CARRIER  ARRIVAL  AT  ISP 

1  CARGO  CARRIER  ARRIVAL  AT  ISP 

1  CARGO  CARRIER  ARkIVAL  AT  ISP 


Figure  IV-16 


NUMBER  2 
NUMBER  1 
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TABLE  2  PIPELINE  -  bULK  POL 


EVENT  SEQUENCED  SUPPLY  LEVELS 


ri«E 

156.4b 
15V. 24 
159.24 
160.00 
161.51 
162.03 
162.03 
163.56 
164.48 
164.48 
16b. 54 
166.54 
166.61 
168.61 

170.68 
170.60 
172.75 
172.75 
174.82 
174.82 
175.00 
175,93 

176.69 

176.69 
177.46 
176.59 

176.71 
1 76 ■ 9b 
178.96 
179.23 

179.66 

179.66 
180.00 
180.00 

180.67 

180,67 

161.69 

181.69 

182.71 

162.71 

183.73 

163.73 


EVP  NT 
TYPF 
N  U  'A  o  E  b 

1 
1 
1 
5 
2 
1 
1 
2 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
5 
2 

1 
1 

2 
3 
3 
1 
1 
2 
1 
1 

5 

6 

1 
1 
1 
1 

L 
1 
1 
1 


ISP 

100.00 

4  «'*  .  0  U 

100. OO 

6  3.7^ 
4  0,00 
24,7a 
64. 7o 
4  0 . 0  0 
15.00 

1  o  v  .  go 

4  0  •  1/ 

1  <J  0  .  U  0 
40.00 
1  0  0  .  G  o 
4  0,00 
100. Co 
4  0.00 
1 Oo.Go 
40.00 
lOu.Uo 
94.76 
40.0b 
15.00 

7  5.00 
40,00 
21.29 
19.  \i 
16,00 
56.2o 
40.00 
15,00 

1  0  0 . 0  u 
79,7a 
79. 7a 
50.11 
100. Oo 

55.25 

100,00 

55.25 
1 0  0  »  0  o 

55.26 
1  0  0  .  y  o 


USER  i 
\ 

6  0.00 
8  0.00 
8  0.00 
6  0.00 
8  0.00 
6  0 . 0  0 
80. uO 
60.00 
7<».32 
6  0.00 
8  0.00 
8  ()  .  0  0 
80.00 
6  0.00 
6  0.0  0 
6  0.00 
80.00 
80.00 
80,00 
60.00 
b(),  oo 
6  0.00 
o  8 . 6  0 
6b  .  60 
66 . 60 
51.88 
50.oo 
46.77 
51  ,H7 
51.67 
51,87 
8  0,00 
60.00 
80,00 
6  0 , 0  0 
60.00 
80.00 
6  0,00 
80.00 
80,00 
6o.OO 
80  .  oO 


2 

90,00 
90.00 
9  0,0o 
90,00 
90,  OO 
90.  Ou 
90.00 
90,00 
89,62 
90.00 
9  0,0  0 
90. 00 
90,00 
90.00 
90.00 
90,00 
9  0 . 0  0 
90.00 

90,00 
90.00 
90.00 
90.00 
69.73 
69.73 
69.73 
4  0.00 
36.67 
2Q.49 
43.12 
43.12 
43.12 

90,00 

9  0.00 
90.00 

9o.0o 
90.00 
90, Ou 
90.00 
90.00 
90.00 
90.  Oo 
90.00 


Figure  iV-17 
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TAPLF  3  PIPELINE  -  nULK  POL 
TIME  SLUUfc'lCED  SUPPLY  LEVELS 


T  1 M  t 


n.oo 
30.00 
60.00 
90.00 
120.00 
150.00 
l fa 0.00 
210.00 
240.00 
270.00 
300.00 
330,00 
360.00 
390,00 
4o0. 00 


USER  NUMBER 


ISP 


100.00 
fi  5 ,  Go 
70, OU 
8».7i 
43.72 
bfa.72 
79.7o 

63.91 

83.91 

83.91 
59.43 

53.31 

96 . 31 

63.31 
7b. 31 


1 


8  0.00 
80.00 
90.00 
80.00 
80,00 
80.00 
HO.  00 
8  0.00 
80.00 
80.00 
6  0.00 
O  0 , 0  0 

fao.oo 
8o ,  00 
80.00 


2 


90.00 
90.00 
90.00 
90.00 
90,00 
90.00 
90.00 
9  0.00 
90. Ou 
90,00 
90.0o 
90.00 
90.00 
9  0,00 
90.00 


Figure  IV-18 
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XAnLh.  4  PIPELINE  -  BULK  POL 
SUPPLY  HATE  VARIATIONS 


EVF'JT 

USER 

NUMRER 

T  Y  V  K 

TIME 

NUMBER 

ISH 

1 

2 

0.00 

0 

6  •  bo 

3.00 

2.50 

85.00 

5 

21.50 

18,00 

2.50 

87.21 

2 

11.  03 

9.44 

0.60 

89.48 

1 

21.50 

16.00 

2.50 

160.00 

6 

29.00 

16.00 

10.0() 

163.58 

2 

27 . 6  2 

17.24 

9.58 

164.48 

1 

29.0o 

IP. 00 

10.00 

175.00 

5 

59.00 

16,00 

40.00 

175.93 

2 

26.0i 

6.13 

16.90 

176.89 

1 

59.00 

16.00 

40,00 

177.48 

2 

16.94 

2.8b 

13. Oh 

178,71 

3 

16,94 

4.95 

10.99 

176.96 

1 

59.00 

1R.00 

40,00 

180.00 

5 

4  4,00 

3.00 

40,00 

290.00 

b 

14.00 

3.00 

10. 00 

320.00 

5 

o,50 

3.00 

2.50 

400,00 

7 

6.60 

3.00 

2.50 

Figure  IV-19 
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day,  when  the  carrier  task  group  (User  Number  1)  increases  its 
demand  from  3.000  barrels  per  day  to  18,000  barrels  per  day.  A 
new  static  pipeline  operation  is  then  set  up,  which  will  have 
cargo  carriers  arriving  every  2.79  days  with  60,000  barrels  of 
fuel.  An  interim  cargo  carrier  with  a  full  load  of  fuel  is 
dispatched  immediately  and  will  arrive  midway  through  the  89th 
day.  On  the  87th  day,  the  ISP  begins  drawing  from  its  emergency 
supplies,  and  the  user's  supply  rates  are  reduced  below  their 
demands.  Thus,  the  users  have  to  draw  from  their  reserves  to 
satisfy  their  full  demands.  On  arrival  of  the  interim  cargo 
carrier  on  the  89th  day,  the  ISP  supply  level  has  just  dropped  to 
its  critical  levl.  The  replenishment  brings  the  ISP's  supply 
level  up  to  its  maximum  storage  capacity  and  also  returns  the 
user  supply  levels  to  their  maximum  levels.  At  this  time,  the 
new  static  pipeline  operation  begins,  and  users'  demands  are  once 
again  satisfied  by  the  ISP. 

This  operation  proceeds  smoothly  until  Day  160,  when 
the  amphibious  task  group  (User  Number  2)  increases  its  demand 
from  2,500  barrels  per  day  to  10,000  barrels  per  day.  A  new 
static  pipeline  operation  is  set  up  with  cargo  carrier  arrivals 
scheduled  2.06  days  apart.  One  already-enroute  carrier  will 
arrive  in  two  days  and  an  interim  cargo  carrier  is  dispatched  to 
arrive  two  days  later.  On  Day  161,  the  ISP  is  forced  to  draw  from 
its  emergency  supplies  but  is  able  to  satisfy  the  user  demands, 
because  the  enroute  cargo  carrier  will  arrive  the  next  day.  When 
this  carrier  arrives,  the  ISP's  supply  level  is  increased  to  a 
point  above  its  emergency  supply  level  but  not  up  to  its  maximum 
storage  capacity  (because  the  arriving  cargo  carrier  was  loaded 
in  accordance  with  the  previous  pipeline  operation) .  On  the  next 
day,  the  ISP  again  begins  to  draw  from  its  emergency  supplies 
and,  at  this  time  it  is  unable  to  satisfy  user  demands.  Thus, 
the  users  are  again  forced  to  draw  from  their  reserve  to  maintain 
their  own  demand.  On  the  subsequent  day,  the  interim  cargo 
carrier  arrives,  and  all  supply  levels  are  returned  to  their 
maximums.  The  static  pipeline  operation  is  then  implemented. 
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On  Day  175,  when  combat  operations  commence,  the 
amphibious  task  group's  demand  increases  to  40,000  barrels  of 
fuel  per  day  and  another  pipeline  operation  is  established,  which 
will  eventually  have  cargo  carriers  arriving  at  1.02  day 
intervals.  However,  in  the  interim  period  of  about  four  and  a 
half  days,  the  pipeline  becomes  severely  stressed.  Near  the  end 
of  the  175th  day,  the  ISP  begins  drawing  on  its  emergency 
supplies  and  must  reduce  its  supply  rate  so  that  the  users  are 
forced  to  draw  from  their  reserves.  This  is  alleviated  late  the 
next  day,  when  a  previously  enroute  cargo  carrier  arrives.  The 
ISP  supply  level  rises  above  its  emergency  level,  but  not  to  its 
storage  capacity.  User  demands  can  be  met,  but  no  surplus  is 
available  to  reduce  user  shortfalls. 

At  the  middle  of  the  next  day  (Day  177),  the  ISP  once 
again  begins  drawing  from  emergency  supplies,  and  user  demands 
cannot  be  satisfied.  On  the  next  day,  both  users'  supply  levels 
drop  below  their  safety  levels.  Later  that  day,  when  the  carrier 
task  group’s  supply  level  is  about  16,000  barrels  above  its 
critical  supply  level,  and  the  amphibious  task  group's  supply 
level  is  only  about  4,500  barrels  above  the  critical  level, 
another  previously  enroute  cargo  carrier  arrives.  This  allows 
the  ISP's  supply  level  to  rise  above  the  emergency  supply  level. 
Because  an  interim  cargo  carrier  with  a  full  cargo  load  is 
scheduled  to  arrive  the  next  day,  the  ISP  is  able  to  make  up  some 
of  the  user  shortfalls  and  still  satisfy  their  demands,  even  when 
its  supply  level  drops  below  its  emergency  supply  level  early  on 
the  next  day  (Day  179).  The  arrival  of  the  interim  cargo  carrier 
later  that  day  allows  all  supply  levels  to  be  returned  to  their 
maximums.  From  this  point  on,  the  pipeline  operation  runs 
smoothly. 

The  remaining  contingency  events  represent  decreases  in 
user  demands.  These  only  cause  a  revision  in  the  cargo  carrier 
scheduling,  with  user  demands  always  being  satisfied.  On  the 
400th  day,  the  task  groups  and  the  service  group  withdraw,  and 
the  pipeline  operations  are  cancelled. 
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D. 


Module  Limitations 

The  SUPPLY  DISTRIBUTION  MODULE  described  in  this  chapter 


represents  an  initial  construct  of  an  analytical  tool  designed  to 
provide  a  basis  for  evaluating  the  distribution  of  supplies  to 
operating  forces  engaged  in  a  theater  war  scenario  within  the 
context  of  BALFRAM.  Although  the  module  was  designed  as  an 
adjunct  to  BALFRAM,  it  can  stand  alone  as  a  useful  tool  in  other 
supply  distribution  analyses.  The  module  design  was  constrained 
by  the  level-of-ef fort  limitations  of  the  present  research 
contract.  Thus,  a  number  of  desirable  features  that  would 
enhance  the  module’s  usefulness  were  not  included.  In  this 
chapter,  the  more  significant  of  these  features  are  identified. 
These  could  be  included  in  a  future  expansion  of  the  module. 

1 .  Multiple  ISPs  Per  Pipeline 

The  present  module  represents  pipelines  designed  to 
service  a  single  ISP.  In  reality,  it  is  more  likely  that 
pipelines  would  be  set  up  to  service  more  than  one  ISP, 
especially  in  situations  where  ISP  and  user  supply  capacity 
limitations  result  in  cargo  carrier  shipments  with  cargo  loads 
much  less  than  each  carrier's  capacity.  Thus,  one  area  for 
module  expansion  is  to  allow  pipelines  to  service  more  than  one 
ISP. 


2.  ISP  and  User  Mobility 

In  the  present  module,  it  is  assumed  that  the  ISP  and 
its  associated  users  remain  at  fixed  stations  or  locations.  For 
naval  operations  especially,  the  users  (task  groups)  are  highly 
likely  to  move  to  an  alternative  station  during  a  given  at-sea 
deployment.  This  implies,  in  many  cases,  that  the  ISP  (service 
group)  providing  support  to  the  users  would  also  move  to 
alternate  stations  to  maintain  proximity  with  its  user  units. 
These  movements  could  be  considered  as  another  category  of 
contingency  events  within  the  structure  of  the  module.  Expansion 
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of  the  module  to  include  this  feature  would  enhance  it3 
usefulness  as  a  supply  distribution  system  evaluation  tool. 


3.  ISP-to-User  Pipelines 

The  present  module  assumes  that  there  is  a  continuous 
flow  of  supplies  from  the  ISP  to  its  associated  users,  with  no 
capacity  limitations  on  this  portion  of  the  pipeline.  Actually, 
the  ISP-to-User  pipelines  are  constrained  in  several  ways.  There 
will  be  limitations  on  the  number  and  capacities  of  intermediary 
cargo  carriers  (ISP-to-User)  such  as  a  truck  convoys  or 
amphibious  supply  ships  servicing  land-based  Marine  forces  from  a 
Mobile  Logistic  Support  Group.  For  sea-based  users  and  service 
groups,  a  user  may  leave  its  station  and  rendevous  with  the  ships 
of  the  service  group,  or  vice  versa.  In  the  former  case,  the 
user  will  be  required  to  be  off-station  some  of  the  time,  and 
this  will  degrade  the  user's  on-station  readiness.  In  the  latter 
case,  an  ISP  supply  ship  will  be  tied  up  servicing  one  user  and 
unavailable,  at  the  time,  to  service  another  user.  These 
limitations  could  have  a  significant  effect  on  the  effectiveness 
of  the  pipeline  operations.  Thus,  it  would  be  fruitful  to  expand 
the  module  to  accommodate  these  restrictions. 

4.  Emergency  Pipelines 

The  present  module  does  not  provide  for  the  use  of 
emergency  pipelines  that  may  be  required  when  the  normal  pipeline 
is  in  a  period  of  stress.  Emergency  pipelines  could  emanate  from 
alternative  supply  sources  and/or,  they  could  utilize  faster 
modes  of  transportation,  such  as  aircraft  or  fast  supply  ships, 
to  speed  up  the  flow  of  supplies  to  the  ISP.  Inclusion  of  this 
feature  in  the  module  would  increase  its  credibility  and  enhance 
its  usefulness. 

5-  Cargo  Carrier  Limitation 

In  the  present  module,  it  is  assumed  that  there  are 
always  enough  cargo  carriers  available  to  the  supply  source  to 

125 


meet  the  requirements  of  a  pipeline  operation.  In  many  cases, 
this  may  not  be  true.  Thus,  a  pipeline  operation  would  have  to 
be  modified  to  accommodate  the  cargo  carrier  limitations.  Quite 
possibly,  more  than  one  pipeline  for  a  given  class  of  supplies 
would  be  needed  to  support  an  ISP.  Inclusion  of  cargo  carrier 
limitations  in  the  module  would  provide  a  more  useful  and 
realistic  tool  for  analyzing  supply  distribution  effectiveness. 

6.  BALFRAM  Integration 

The  module,  as  presently  designed,  is  a  separate 
adjunct  to  BALFRAM.  The  main  drawback  is  that  the  module  is  not 
reactive,  in  realtime,  to  user  demands  that  would  vary  in  a 
BALFRAM  scenario.  Joint  usage  of  BALFRAM  and  the  module  would 
first  require  a  BALFRAM  run  to  establish  the  requirements  imposed 
on  the  pipelines  providing  supplies  to  the  theater  area.  Then  a 
set  of  module  runs  would  be  required  to  iterate  on  a  solution 
defining  the  pipeline  characteristics  necessary  to  meet  these 
requirements.  A  worthwhile  module  modification  would  be  to 
provide  for  concurrent  integrated  operation  with  BALFRAM,  where 
the  necessary  pipeline  adjustments  can  be  established  as  BALFRAM 
supply  requirements  change. 
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Figure  IV- 20  SAMPLE  PROBLEM  OUTPUT  TABLES  (Continued) 
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Figure  IV-20  SAMPLE  PROBLEM  OUTPUT  TABLES  (Continued) 


Figure  IV-20  SAMPLE  PROBLEM  OUTPUT  TABLES  (Continued) 


TIME  bEiJUtNCED  SUPPLY  LEVELS 


Figure  IV-20  SAMPLE  PROBLEM  OUTPUT  TABLES  (Continued) 


Figure  IV-20  SAMPLE  PROBLEM  OUTPUT  TABLES  (Concluded) 
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APPENDIX 


SUPPLY  DISTRIBUTION  MODULE  COMPUTER  PROGRAM 


A.  Input  Formats .  A-1 

B.  Program  Nomenclature  .  A-4 

C.  Program  Listing .  A-13 


A. 


Input  Formats 

All  inputs  to  the  SUPPLY  DISTRIBUTION  MODULE  Computer 


Program  are  read  from  a  series  of  input  data  cards,  or 
equivalently,  from  an  input  data  file  containing  80  character 
data  records  (each  input  record  corresponding  to  an  input  data 
card).  Table  A-1  presents  a  summary  description  of  each  input 
data  card  including  the  card  formats,  input  variables,  variable 
descriptions,  and  variable  measurement  units.  Some  of  the  card 
numbers  apply  to  a  set  of  input  cards.  For  example.  Cards  6.P.I 
refer  to  a  set  of  NB  data  cards  for  Pipline  P's  set  of  data 
cards,  where  NB  is  the  number  of  users. 


A-1 


INPUT  DATA  CARDS 


Program  Nomenclature 
1 .  Program  PIPLIN 


BCL( I , P) 
BIG(I) 

BIP(I,P) 

BIR(I,P) 
BL(I,P) 
BML(I , P) 
BP(I,P) 

BPOLD 

BR(I,P) 

BS(I,P) 

BSL(I,P) 

BSOLD 

CAR 

CL(P) 

CLI 

CLOLD 

CLP 

CT 

CUD(NCO.P) 


Critical  supply  level  for  User  I  for  Pipeline  P. 
Indicator  denoting  whether  or  not  User  I  is 
active  (BIG(I)=0,No;  BIG(I)=l,Yes) . 

Present  normal  essential  priority  for  User  1 
for  Pipeline  P. 

Initial  demand  rate  for  User  I  for  Pipeline  P. 
Present  supply  level  for  User  I  for  Pipeline  P. 
Maximum  supply  level  for  User  I  for  Pipeline  P. 
Present  essential  priority  for  User  I  for 
Pipeline  P. 

Previous  essential  priority  for  user  and  pipeline 
being  processed. 

Present  demand  rate  for  User  I  for  Pipeline  P. 

Present  supply  rate  for  User  I  for  Pipeline  P. 

Safety  supply  level  for  User  I  for  Pipeline  P. 

Previous  supply  rate  for  user  and  pipeline 
being  processed. 

Amount  of  expected  shortfall  to  be  made  up  at 
time  of  contingency  event  being  processed. 

Cargo  carrier  load  for  Pipeline  P. 

Cargo  carrier  load  for  next  scheduled  cargo 
carrier  for  pipeline  being  processed. 

Previous  value  of  cargo  carrier  load  for  pipe¬ 
line  being  processed. 

Cargo  carrier  load  for  next  scheduled  non-enroute 
cargo  carrier  for  pipeline  being  processed. 

Current  time. 

User  demand  rate  for  Pipeline  P  after  occurrence 
of  contingency  event  NCO. 

User  number  associated  with  contingency  event  NCO. 

A-A 


CUN (NCO) 


Program  PIPLIN,  continued 


CUP(N'CO,  P) 

DC( J , P) 

DELT 

DT ( J , P ) 

ESP (P) 

ET 

I 

IC 

IJ 

IP 

IP1 

IP2 

IP3 

IP4 

IT1 


User  essentiality  priority  number  for  Pipeline 
P  after  occurrence  of  contingency  event  NCO. 

Cargo  carrier  load  for  cargo  carrier  J  in 
Pipeline  P. 

Difference  in  time  of  arrival  between  next 
scheduled  non-enroute  cargo  carrier  and  last 
scheduled  enroute  cargo  carrier  for  pipeline 
being  processed. 

Cargo  carrier  arrival  time  for  cargo  carrier 
J  in  Pipeline  P. 

Indicator  denoting  whether  or  not  ISP  is 
drawing  from  emergency  supplies  for  Pipeline  P. 
Event  type  number  for  event  currently  being 
processed . 

Index  number  for  user  (also  used  as  a  dummy 
index) . 

Contingency  pipeline  counter. 

Indicator  denoting  whether  or  not  there  is 
another  contingency  event  involving  an  active 
user  (IJ=0,No;  IJ=l,Yes) . 

Dummy  index  number  for  pipelines. 

File  number  of  Event  Chronology  Table  for 
pipeline  being  processed. 

File  number  of  Event  Sequenced  Supply  Level 
Table  for  pipeline  being  processed. 

File  number  of  Time  Sequenced  Supply  Level 
Table  for  pipeline  being  processed. 

File  number  of  Supply  Rate  Variation  Table  for 
pipeline  being  processed.  * 

Number  of  new  interim  cargo  carriers  to  be 
scheduled  immediately  for  pipeline  and  contingency 
event  being  processed. 

Integer-valued  scheduled  run  duration. 

A- 5 


ITDUR 


Program  PIPLIN,  continued 


ITEM 


ITERM(P) 

ITP 

TW 


J 

JE 

JJ 

JP 

JT 

K 

KP 

MCS(P) 

MD(P) 

MDOLD 

MDP(P) 

MDR(P) 

MES(P) 

MK(K) 

MOT(P) 


Number  of  new  interim  cargo  carriers  to  be 
scheduled  for  pipeline  and  contingency  event 
being  processed. 

Indicator  denoting  whether  or  not  Pipeline  P 
has  stabilized  ( ITERM(P) =0 , No ;  ITERM( P) =1 , Yes) . 
Integer-valued  printout  interval. 

Indicator  denoting  whether  or  not  event  being 
processed  is  a  User  Withdrawal  Event  (IW=0,No; 
IW=l,Yes) . 

Index  number  for  scheduled  cargo  carrier  (also 
used  as  a  dummy  index) . 

User  number  or  special  event  number  (NB1,  NB2, 
or  NB3) . 

Dummy  index  used  to  denote  contingency  event 
number. 

Pipeline  number  generating  event  to  be  processed. 
User  number  generating  contingency  event  that  is 
to  be  processed. 

Dummy  index  used  to  denote  contingency  event 
number . 

Dummy  index  number  for  pipelines. 

ISP  critical  stores  level  for  Pipeline  P. 

Present  total  demand  rate  on  the  ISP  for 
Pipeline  P. 

Previous  total  demand  rate  on  ISP  for  pipeline 
being  processed. 

Present  total  user  demand  rate  on  the  ISP  for 
Pipeline  P. 

ISP  own  supply  demand  rate  for  Pipeline  P. 

ISP  emergency  stores  level  for  Pipeline  P. 

Dummy  array  used  to  transfer  output  from  in¬ 
ternal  files  to  program  output  file. 

ISP  order  time  for  Pipeline  P. 

A- 6 


ram  PIPLIN,  continued 


MSC(P)  ISP  storage  capacity  for  Pipeline  P. 

MSD(P)  Transit  distance  between  supply  source  and 

ISP  for  Pipeline  P. 

MSU(P)  Cargo  carrier  unloading  rate  at  ISP  for  Pipe¬ 

line  P. 

N  Dummy  index  used  to  denote  contingency  event 

number . 

NB  Number  of  users. 

NB1  Special  event  number  for  ISP  related  event 

(NB1=NB+1) . 

NB2  Special  event  number  for  contingency  event 

(NB2=NB+2) . 

NB3  Special  event  number  for  scheduled  run  control 

operation  (NB3=NB+3) . 

NC(P)  Number  of  cargo  carriers  required  to  maintain 

static  pipeline  operation  for  Pipeline  P. 

NCI  Number  of  cargo  carriers  scheduled  for  static 

pipeline  operation  for  pipeline  being  processed. 

NCO  Index  number  for  contingency  event. 

NC01  Dummy  index  used  to  denote  contingency  event 

number . 

NIC (P)  Number  of  interim  cargo  carriers  in  Pipeline  P. 

NIC1  Index  number  denoting  first  scheduled  cargo 

carrier  for  static  pipeline  operation  for  pipe¬ 
line  being  processed. 

NOC  Number  of  contingency  events. 

N0C1  Index  number  denoting  one  more  than  the  number 

of  contingency  events. 

NTC(P)  Total  number  of  scheduled  cargo  carriers  in 

Pipeline  P. 

Index  number  for  pipelines. 

Pipeline  name  for  Pipeline  P. 

A- 7 


P 

PN(P) 


Program  PIPLIN,  continued 


REM 


SCC(P) 

SCL(P) 

SCS(P) 

SDT(P) 

SE(I,P) 


SFM 

SFM1 

SFM2 


SL(P) 

SLT 

SOF 

SPR(P) 

SR(P) 

SROLD 

SRP(P) 

SRT 

T 

TC(NCO) 

TCM 


Dummy  variable  used  to  denote  the  difference 
between  the  real  value  and  the  integer  value  of 
a  variable. 

Cargo  carrier  capacity  for  Pipeline  P. 

Cargo  carrier  loading  rate  for  Pipeline  P. 

Cargo  carrier  speed  for  Pipeline  P. 

Cargo  carrier  recycle  downtime  for  Pipeline  P. 
Next  event  type  for  User  I  (1=1,..., NB)  or 
Special  Event  I  (I=NB1,  NB2,  or  NB3)  for  pipe¬ 
line  P. 

Total  amount  of  supply  surplus  that  can  be 
distributed  for  pipeline  being  processed. 

Amount  of  supply  surplus  that  can  be  distributed 
immediately  for  pipeline  being  processed. 
Additional  amount  of  supply  surplus  that  can  be 
distributed  before  arrival  of  next  scheduled 
cargo  carrier  for  pipeline  being  processed. 
Present  ISP  supply  level  for  Pipeline  P. 

ISP  supply  level,  including  any  surplus,  that 
may  be  available  for  pipeline  being  processed. 
Projected  supply  overfall  for  pipeline  being 
processed . 

Cargo  preparation  rate  for  Pipeline  P. 

Present  ISP  supply  rate  for  Pipeline  P. 

Previous  ISP  supply  rate  for  pipeline  being 
processed . 

Present  user  supply  rate  for  Pipeline  P. 

Maximum  allowable  ISP  supply  rate  for  pipeline 
being  processed. 

Dummy  variable  used  in  determining  time  of  next 
event  to  be  processed. 

Time  of  occurrence  of  Contingency  Event  NCO. 

Maxumum  allowable  time-between-arr ivals  for 

cargo  carriers  at  ISP  for  pipeline  being  process 
A- 8 


Program  PIPLIN,  continued 
TCP 

TCY(P) 

TDUR 
TE( I , P) 

TEM 

TEM1 

TFA 

TL 

TLA 

TLAR(P) 

TLE(P) 

TN 

TP 

TPA 

TR(P) 

TSA 

WB(I) 


Cargo  carrier's  cycle  time  for  pipeline  being 
processed . 

Cargo  carrier's  maximum  cycle  time  for  Pipeline 

P. 

Real-valued  scheduled  run  duration. 

Next  event  time  for  User  I  (1=1,..., NB)  or 
Special  Event  I  (I=NB1,  NB2 ,  or  NB3)  for 
Pipeline  P. 

Dummy  variable  used  for  several  diverse  compu¬ 
tations  . 

Dummy  variable  used  to  determine  time  of  occur¬ 
rence  of  next  contingency  event  involving  an  active 
user . 

Time  of  arrival  of  first  possible  newly  scheduled 
cargo  carrier  for  pipeline  being  processed. 

Time  of  arrival  of  last  enroute  cargo  carrier 
for  pipeline  being  processed. 

Time  of  arrival  of  last  interim  cargo  carrier 
for  pipeline  being  processed. 

Time  of  arrival  of  previous  arriving  cargo 
carrier  for  Pipeline  P. 

Time  of  last  processed  event  for  Pipeline  P. 

Time  of  arrival  of  next  departing  cargo 
carrier  for  pipeline  being  processed. 

Real-valued  printout  interval. 

Possible  time  of  arrival  of  next  non-enroute 
cargo  carrier  for  pipeline  being  processed. 

Number  of  supply  days  provided  by  a  cargo 
carrier  to  an  ISP  in  Pipeline  P. 

Time  of  arrival  of  next  scheduled  non-enroute 
cargo  carrier  for  pipeline  being  processed. 

Supply  allocation  weighting  factor  for  User  I 
for  pipeline  being  processed. 

A-9 


A 


Subroutine  REVISE 

CL(P)  Cargo  carrier  load  for  Pipeline  P. 

MD(P)  Demand  rate  on  ISP  for  Pipeline  P. 

MES(P)  Emergency  supply  level  for  ISP  for  Pipeline  P. 

MSC(P)  Storage  capacity  for  ISP  for  Pipeline  P. 

MSU(P)  Cargo  unloading  rate  for  ISP  for  Pipeline  P. 

NC(P)  Number  of  cargo  carriers  required  to  maintain 

Pipeline  P. 

P  Index  number  for  pipeline  being  processed. 

REM  Dummy  variable  used  in  determining  NC(P) . 

SCC(P)  Cargo  carrier  capacity  for  Pipeline  P. 

SCL(P)  Cargo  loading  rate  at  supply  source  for  Pipeline 

P. 

SPR(P)  Cargo  preparation  rate  at  supply  source  for  Pipe¬ 

line  P. 

TCM  Maximum  allowable  time-between-arrivals  for  cargo 

carriers  at  ISP  for  pipeline  being  processed. 

TCP  Cargo  carrier's  cycle  time  for  pipeline  being 

processed. 

TCY(P)  Cargo  carrier's  maximum  cycle  time  for  Pipeline 

P. 

TEM  Dummy  variable  used  in  determining  TR(P)  and  NC(P). 

TR(P)  Number  of  supply  days  provided  by  a  cargo  carrier 

to  an  ISP  in  Pipeline  P. 

Subroutine  NEXTEV 

BCL(I,P)  Critical  supply  level  for  User  I  for  Pipeline  P. 
BIG(I)  Indicator  denoting  whether  or  not  User  I  is 

active  (BIG(I)=0,No;  BIG(I)=l,Yes) . 

BL(I,P)  Present  supply  level  for  User  I  for  Pipeline  P. 

BR(I,P)  Present  demand  rate  for  User  I  for  Pipeline  P. 

BS(I,P)  Present  supply  rate  for  User  I  for  Pipeline  P. 

BSL(I,P)  Safety  supply  level  for  User  I  for  Pipeline  P. 

CT  Current  time. 

I  Index  number  for  user. 


Subroutine  NEXTEV,  continued 


XB  Number  of  users. 

P  Index  number  for  pipeline  being  processed. 

SE(I,P)  Next  event  type  number  for  User  I  for  Pipeline  P. 

TE(I,P)  Time  of  occurrence  of  next  event  for  User  I  for 

Pipeline  P. 

4 .  Subroutine  ALLOC 

B(I)  Ratio  of  present  essential  priority  to  present 

demand  rate  for  User  I. 

BIG(I)  Indicator  denoting  whether  or  not  User  I  is 

active  (BIG(I)=0,No;  BIG(I)=l,Yes) . 

BP(I,P)  Present  essential  priority  for  User  I  for  Pipe¬ 

line  P. 

BR(I,P)  Present  demand  rate  for  User  I  for  Pipeline  P. 

I  Index  number  for  user. 

NB  Number  of  users. 

P  Index  number  for  pipeline  being  processed. 

PRO  Product  of  all  B(I)'s. 

SUM  Sum  of  weighting  factors  (unnormalized) . 

WB(I)  Supply  allocation  weighting  factor  for  User  I 

for  pipeline  being  processed. 

5.  Subroutine  SHTFAL 

BIG(I)  Indicator  denoting  whether  or  not  User  I  is 

active  (BIG(I)=0,No;  BIG(I)=l,Yes) . 

BIP(I,P)  Present  normal  essential  priority  for  User  I 

for  Pipeline  P. 

BL(I,P)  Present  supply  level  for  User  I  for  Pipeline  P. 

BML ( I , P )  Maximum  supply  level  for  User  I  for  Pipeline  P. 

BP(I,P)  Present  essential  priority  for  User  I  for  Pipe¬ 

line  P. 

BSL(I,P)  Safety  supply  level  for  User  I  for  Pipeline  P. 

I  Index  number  for  user. 

A-ll 


Subroutine  SHTFAL,  continued 


NB 

P 

SE(I,P) 
SF(  I) 

SFM 

SL(P) 

SSF 


Number  of  users. 

Index  number  for  pipeline  being  processed. 

Next  event  type  number  for  User  T  for  Pipeline  P. 
Dummy  variable  used  to  denote  shortfall  for  User 
I  for  pipeline  being  processed. 

Supply  surplus  for  pipeline  being  processed. 

ISP  supply  level  for  pipeline  P. 

Shortfall  existing  for  users  for  Pipeline  P. 


* 
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2 

3 

4 

5 

6 

7 
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9 

10 

It 

12 

13 

14 

15 

16 

17 

18 
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22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

60 
61 


gram  Listing 


PROGRAM  PIPLIN 

COMMON  /BLOCK!/  TCN , NSC! 3 ) , MES ! 3 ) , ND ! 3 ) , SCC ! 3 ) , TR ! 3 ) , 

1  CLC 3) ,TCY(3) ,TCP,SPR(3) ,SCL(3) , 

2  MSU( 3) ,NC(3) 

REAL  MD,MSC,MSU,MES 

COMMON  /BLCCK2/'NB,BIG!lO),SE!13,3),TE!13,3),BLIl0,3),BSLtlO,3), 

1  BML!10,3),BCL!10,3),BR!10,3),BIR!10,3),BS!10,3),BP!10,3), 

2  BIP!10,3),mBC10),SL!3),SFN,CT 

INTEGER  SE,BIG 

DIMENSION  0C( 1«0 , 3), DT< 100, 3) ,TC!99) ,CUD!99, 3) ,CUP! 99, 3), 

1  5CS!J),SDT(3),5R(3),SRP(3),NIC(3),NTC(3),TLEC3), 

2  ITERM!J),TLAR!3> 

REAL  MDR(3),MDPC3) ,HCSC3) ,M6D!3) ,N0T!3) ,MDOLD 
INTEGER  CUN!99),ESP!3),EI,P 
CHARACTER*!  MK(i32) 

CHARACTER*30  PN13) 

1000  PORMATC2I6) 

tool  FoRMAT!F9.i,F5.i,F9.i,F9,i,r5,i) 

1002  roRMAT(r9.i,r9,i,r7.2,r9.i,r9.i,r9,2,r5.i> 

1003  F0RMAT!F7.2,F5.3,F9.1,r9,l,F9,l) 

1004  rORNAT!I2,r7.1,ir7,2,3F5,3> 

1005  FORMAT! 132A1 ) 

1006  F0RMAT(I2) 

1007  FORMAT! A30) 

2000  FORMAT!TSfr9.2,I22,ll!F8t2.1X)) 

2001  F0RHAT!T2,F9.2,il6,Xl,T22,ll!rB.2,lX)) 

2011  FORNAT!T5,F9.2,T20,lHl,T3t,28HCARGO  CARRIER  ARRIVAL  AT  ISP) 

2012  FORMAT !T5,F9. 2, T20,lH2fT3l,28HTSP  DIPPING  INTO  EMERGENCT  S, 

1  7HUPPLIES) 

2013  F0RmAT!T5,F9.2,*20,1H3,T31,53HSUPPLY  LEVEL  DROPS  BCLOM  SAFETY  LCVE 
1L  —  USER  NUMBER  ,12) 

2014  FORMAT!T5,F9.2,*20,1H4,T31,$OHSUPPLY  LEVEL  REACHES  CRITICAL  LEVEL 
1—  USER  NUMBER  « I2/T35, 41HU5ER  MITHDRAMS  —  INSTIGATING  PIPELINE  - 

2  ,A30) 

2015  F0RNAT!T5,F9.2,T20,1H5,T31,26HC0NTINGENCY  EVENT  —  USER  , 

1  7HNUMBER  ,12) 

2016  F0RMAT!T5,F9.2,I20,1H6,T31,23HR0UTINE  PRINT-OUT  EVENT) 

2017  FORMAT! T5 ,F9, 2, T20, 1H7»T31,27HRUN  TERMINATED  BEFORE  LAST  , 

1  IlHCONTINGbNCYHAS  BEEN  STABILIZED) 

2018  FORMAT!TS,F9.2,I20'1H7,T3!,26HRUN  TERMINATED— ALL  USERS  , 

1  14HHAVE  MITHORAWN) 

2019  rORMAT!TS,F9,2,t2Q,iH7'T31,27HRUN  TERMINATED— ISP  CANNOT  , 

1  20HMAINTAIN  SELF-SUPPLY, 3X, 11HPIPELINE  -  ,A30) 

2020  FORMAT! T5 ,F9, 2 ,'i20 ,1H7,T31,21HRUN  TERMINATED— LAST  , 

1  31HC0NTINGENCY  HAS  BEEN  STABILIZED) 

2021  F0RMAT!T5,F9.2,T20,1H7,T31,31HRUN  TERMINATED— SLIP) .NE.MESIP) , 

1  3X , 1 1HPIPELINE  -  , A30 ) 

2022  FORMAT! T5,F9, 2, '^20, 1H7,T31,27HRUN  TERMINATED— BL! I, P)  ,NE,  , 

1  11HBSL!I,P),I>,I2,3X,11HPIPELINE  -  ,A30) 

2023  F0RMAT!TS,F9,2,T20,1H7,T31,27HRUN  TERMINATED— BL!I ,P) . NE, , 

1  1 1 HBCL! I ,P),Im,I2,3X,11HPIPELINE  -  ,A30) 

2024  F0RMAT!T5 ,F9, 2,T20, 1H7 ,T31,25HUSER  HITHDRANS  AND  THERE  , 

1  31HARE  NO  INTERIM  CARRIERS  ENROUTE, 3X, 1 1HPIPELINE  -  ,A30) 

2025  FORMAT !T31 , 32HRUN  TERMINATED— INPUT  READ  ERROR) 

3001  FORMAT! 1 HI /////f 45, 7HT ABLE  1 , 3X , 1 1 HPIPELINE  >  , A30//T53 , 1 6HEVENT  C 
1HRONOLOGY/T18,5HEVENT/T19,4HTYPE/T8,4HTIME,T19,6HNUMBER,T50, 

2  17HEVENT  DESCRIPTION//) 

3002  FORMAT! 1  HI /////t45,7HT ABLE  2 , 3X , 1 1HPIPELINE  -  , A30//T47 , 16HEVENT  S 
1C0UENCE0  , liHSUPpLY  LEVELS/T1 4, 5HEVENT/T15 , 4HTYPE, T56 , 

2  11HUSER  NUMBER/ T5 , 4HTZME,T1 4 ,6KNUMBER,T25,3HISP,T35,1H1, 

3  T44,1H2,TS3,1H4,T62,1H4,T71,1H5,T80,1H6,T89,1H7,T98,1H8, 
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*TJT” 


62 

63 

64 
6$ 
66 

67 

68 

69 

70 

71 

72 

73 

74 
79 

76 

77 

78 

79 

90 

91 
82 

83 

84 
89 
96 
87 

98 

89 

90 

91 

92 

93 

94 

99 

96 

97 
99 
99 

100 

101 

102 

103 

104 
109 
106 
107 
109 

109 

110 
111 
112 

113 

114 
119 
116 

117 

118 

119 

120 
121 
122 


4  T107,1H9,T119,2H10//) 

3003  F0RMAT(1H1/////I45,7HTABLE  3 , 3X , l 1HPIPELINE  •  , A30//T48 , 15HTIME  SC 
1QUCNCCD  ,13HSUPPLY  LEVEL5//T56 , 1 1HUSCR  NUMBER/T8, 4HTXME,I25,3HISP, 

2  T39,1H1,T44,1H2,TS3,1N3,T62,1H4,T71,1HS,T80,1H6,T99,1H7, 

3  T98,1H8,T107,1H9,T11S,2H10//) 

3004  FORNAT( lHl/////f 45 , 7H TABLE  4, 3X, 1 1HPIPCLINE  -  , A30//T50, 1 1HSUPPLY 
IRATE, 1 1 H  VARlATiON8/T14,9HEVCNT/T19,4HTYPE,T56, 

2  1IHUSER  NUMBER/T5 , 4HTIME, T1 4, 6HNUMBER ,T25 , 3HI5P, T35 , 1H1 , 

3  T44,1H2,TS3,1HJ,T62,1H4,T71,1H9,T60,1H6,T89,1H7,T98,1H8, 

4  Ti07,lH9,T115,2H10//> 

OPEN (UNITB5,FILt*'PIPLXN. DAT*, READONLY, STATUS**OLD*> 

0PEN(UNIT*7 ,FXl£**PIPLXN, LIS* ,  STATUSb'NEW*) 

OPEN <UNIT*8, STATUS* 'NEW*, DXSP«*DELETE') 

OPEN (UNXT*9 , STATUS* 'NEW  *,DX3P**DCLETE*) 

OPEN(UNIT*10,STATU6*'NEW' , D ISP*' DELETE') 

OPEN (UNI T*1 1 , ST ATUSa'NEW* ,DX3P* 'DELETE ' ) 
0PEN(UNIT*12,STATUS*'NEW',DISP*'DELETE') 

OPEN (UN IT»1 3 , STATUS* 'NEW ', DI3P* 'DELETE ' ) 

OPEN (UNITal 4 ,STATUSa 'NEW*, OX SPb'DELETE*) 

OPEN ( UN IT*1 5 , STATUS*' NEW' , DISP*'DELETE ' ) 

OPEN ( UN  I T*16 , STATUS*' NEW ' ,DI5P*' DELETE' ) 

OPEN (UN XT* 17 , STATUS** NEW *, DXSP* 'DELETE') 

OPEN (UNXT*1 8 ,STATUS**NEW * ,DI5P* 'DELETE') 

RE AO ( 9 , 1 000 , EKR*900 , EN0*900 J  XTP, XTDUR 

TP«l.*ITP 

TDUR*1 , *ITDUR 

RE AD (9, 1006) NS 

DO  3  P*1 ,3 

READ(5,1007)PN(P) 

IP1*3+4*P 

IP2*4a4*P 

IP3*9*4*P 

IP4»6*4*P 

WRITE (IP1, 3001 )PN(P) 

WRITE(IP2,3002)PN(P) 

WRXTE(IP3,3003)PN(P) 

WRITE(IP4,3004)PN(P) 

READ(5,100l , ERR*9U0 , CND*900 )  SCCCP) ,SCS( P) , SCL(P) ,SPR (P) 

1  ,SDT(P) 

REA0(9 , 1002 , ERR*9U0 , END*900 )  NSC(P) ,RSU(P) ,NDR(P) ,MES(P) , 

1  MCS(P) , NSDIP) , MOT(P) 

DO  1  1*1, NS 

READ(S , 1003 ,ERK*900 ,CND*900)BXR (X ,P) ,BXP(X,P), BML(  I ,P),B8L(X,P), 

1  BCL(I,P) 

1  CONTINUE 
3  CONTINUE 

READ (9, 1006) NOC 
DO  2  1*1 ,NOC 

READ (9 , 1 004 , END*900 , ERR*900 ) CUN( I ) ,TC( X) , (CUD( I ,P) ,P*1,3), 

1  (CUP(X,P),P*1,J) 

2  CONTINUE 
N0Cl*N0C4l 
TCCN0C1 )*1E9 

®  • 

C  ESTABLISH  STATIC'  PIPELINE  FLOW  PARAMETERS  AND  CARRIER  DELIVERY 

C  TINES, 

C 

00  16  P*l, 3 
MO(P)*NOR(P) 

DO  10  1*1, NS 
10  NO(P)*ND(P)tBXR(X,P) 
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123 

124 

125 

126 
122 
128 
129 
1)0 
1)1 

132 

133 

134 

135 

136 
1)2 

138 

139 

140 

141 

142 

143 

144 

145 

146 
142 

148 

149 

150 

151 

152 

153 

154 

155 

156 
152 

158 

159 

160 
161 
162 
161 

164 

165 

166 
162 
168 
169 
120 
121 
122 
121 

124 

125 

126 
122 
128 
129 
180 
181 
182 
183 


M0P<P)aND(P)-MD»<{P) 

TCT(P)a{l* /SPH(P)*1 «/5CL (P) *1 ,/N6U(P) ) *SCC(P)  ♦ 

1  2*MSD(P>/(34,«SCS<P)>  ♦  SDT(P) 

CALL  REVISC1PJ' 

SR (P)aMD(P) 

SRP(P)aMDPlP) 

SLlPJaMSCCP) 

ESP(P)a0 

NTC(P)aNC(P)*l 

NIC(P)a0 

DO  15  Jal.NTCIPl 
DT(J,P)»J*T«1P) 

15  OCCJ*P)«CL(P) 

16  CONTINUE 
C 

C  INITIALIZE  RUNNING  PARAMETERS 
C 

IC«0 

Jpal 

NBlaNB+t 

HB2»na*2 

NB3aNB+3 

NCQal 

IHaO 

DO  25  Pal * 3 
IP2«444*P 
IP3a5*4*P 
IP4a6+4*P 
TLEl P)aO, 

DO  20  Xal ,  NB 

8R(I,P)a8IR(I*PJ 

BPCI,P)aBIP(I*Pj 

RLH»P)a8NL(l#Pi 

B3(I,P)aBIRU,P> 

TEU,P)alE9 
SE(X,P)aO 
20  BIGtl)al 
CTaO, 

ET»0 

TE(NBl,P)aDT(l,P) 

SE<N8l , PJal 
TE{N82,P)aTCU) 

3E(N82,P)aS 

TE(NS3,P)atP 

SC(N»3,P)a6 

MRITEaP2,2001)tT,eT,SL(PJ,(BL(I#P),I»l,HB) 

WRITE! IP3  *2000 )CT* SLIP)  ,(BL!I*P)*lal*R8) 
MRlTElIP4,2001jeT,ET,SR(P),(BSCI.P)*I«l,«S} 

25  CONTINUE 

50  TL8(JP)aCT 

c 

C  DETERMINE  NEAT  EVENT  TIME*  PARTICIPANT,  AND  TTPE  TO  BE 

C  PROCESSED, 

C 

51  TalElO 
JEaO 

DO  55  Pal, 3 
DO  55  lal*NS3 
IP(T,LC,TE(l*P)3  GO  TO  56 
T>TE(1 *P) 
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184 

185 

186 

187 

188 

189 

190 

191 

192 

193 

194 
199 

196 

197 

198 

199 

200 
201 
202 

203 

204 
209 
206 

207 

208 

209 

210 
211 
212 

213 

214 
219 
216 

217 

218 

219 

220 
221 
222 

223 

224 
229 
226 

227 

228 

229 

230 

231 

232 

233 

234 
239 

236 

237 

238 

239 

240 

241 

242 

243 

244 


JEal 

JPap 

99  CONTINUE 

xrcjc.ea.oiGo  to  9000 
ir(SECJE,JP),NE.5)G0  TO  99 
JTaCUN ( NCO) 

irtBtGC JT).£Q.1JGU  TO  59 
NCOaNCO+1 
DO  97  Pal ,3 
TE(NB2#P)aTC(NCU) 

97  CONTINUE 
GO  TO  91 
99  CTaT 

ETaSE(JE,JP) 

PaJP 

IPlaJ*4*P 

IP2a4*4*P 

IP3b9*4*P 

IP4a6*4*P 

C 

C  COMPUTE  PRESENT  SUPPLY  LEVELS 
C 

DO  60  ial,NB 

BL(l,P)a8L(l,P)«(UR(X,P)-BS(X,P>)*(CT»TLE(P)) 
60  CONTINUE 

3L(P)aSUP)-SR<PJ*CCT-TLE(P) ) 

IFIET.EO.SJGO  TU  500 

NRITE(IP2,2001)CT,ET,SL(P),tBLtI,P),Iai,NB) 

GO  TO  UOO, 200,300, 400, 500, 600,700>ET 
C 

C  PROCESS  THE  ARRIVAL  Or  A  CARGO  CARRIER 
C 

100  3L(P)bSLCP)«0C(1,P) 

TLAR(P)aCT 

SROLOaSR(P) 

ITERM(P)aO 
WRITE(IP1,2UU)GT 
IF(NIC(P).Nb,0)Ci0  TO  109 
ITERM(P)al 

IFCNCO.GT.NOCJGO  TO  104 

101  DO  102  la2."TC(P) 

DTtI-l,P)aOT(I,l*> 

DCII-1, P)a0C(I,P) 

102  CONTINUE 

DT(NTCCP>,P)bUTINIC<P)-1,P)*TR(P) 

DC(NTC(P),P)aOC<NTC(P>-l,P) 

ESP(P)aO 

TE(NBl,P)aOT(l,F) 

NRITEI  IP2,2001)CT,ET,  SLIP),  <BL(I f P) , I«1 ,NB) 

GO  TO  90 

104  00  103  I P«1 « 3 

ir<iP.ca.p>Go  tu  los 

IF( ITERM(IP) «NC> 1 )G0  TO  101 

103  CONTINUE 
ETaT 

DO  1090  P*1 i 3 

IPla3*4«P 

IP2«4*4«P 

IPJaS*4«P 

IP4a6«4*P 

«RITE(IP2,2001)CT,ET,SL(P),(BLCI,P)fIai,NB) 
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243  WRITEdP3,2000)CT,5L(P),  C Bt d , P> , I ■! , «B) 

246  WRITE  dP4, 2001  )CT,ET,  SR  (P),(BSd,P>,  1*1,  NB) 

247  WRITE(IP1,2020)Ct 

248  1050  CONTINUE 

249  CO  TO  9000 

250  103  CONTINUE 

251  00  107  t*2,NTC(P) 

252  DTd-l,P)*OTd,P) 

253  0Cd-l,P)«0Cd,P) 

254  107  CONTINUE 

255  TE(NBl,P)aOICl,P) 

256  NTC(P)*NTC(P)-1 

257  NIC(P)«NIC(P)-1 

258  IFCSLCP).LE.ME31P}4.01)G0  TO  120 

259  SR(P)aND<P) 

260  DO  110  I»1 ,NB 

261  BSd,P)aBIGd)*#Rd,P) 

262  TEd,P)alE9 

263  110  CONTINUE 

264  lF(SROL0.NE.5R<P))WRITEdP4,200i)CT,ET,SR(P),(BSd,P),Ial,NB) 

265  IF(SLCP).GT.MSClP))GO  TO  113 

266  SFNlaO, 

267  GO  TO  140 

268  115  SFN1>SI,(P)-MSC{P) 

269  GO  TO  140 

270  120  CONTINUE 

271  SFN1*0. 

272  SRTaf3b(P)-NCS<P))/(DTCl,P)-CT) 

273  IF(SRT.LT.NU(P))GO  TO  128 

274  SR(P)aMDCP) 

275  DO  124  1*1, NB 

276  B3d,P)aBXGd)*»Rd,P) 

277  TEd,P)"lE9 

278  124  CONTINUE 

279  IF(SR0L0.NE.5H(P))NRITEdP4,2001)CT,ET,SR(P),CBSd,P),Iai,NB) 

280  GO  TO  140 

281  128  SR(P)aSRT 

282  SRP(P)*3R<PJ-MDK(P) 

283  MDP(P)*ND<Pj-MOK(P) 

284  IF(SRP(P) .GE.O.iGO  TO  132 

283  ETa7 

286  DO  130  Pal ,3 

287  IP1«344*P 

288  IP2*444*P 

289  IP3*5*4*P 

290  IP4a6*4«P 

291  NRITEdPl, 2019)01, PN(JP) 

292  WRITE  dP2, 2001)  CT,ET,SL(P)»(BLd»P), 1*1, NB) 

293  9RITEdP3,200O)OT,SL(P),(BLd,P),Ial,NB) 

294  HRITEdP4,2001)CT,ET,3R(P),(B3(X,P),lai,NB) 

293  130  CONTINUE 

296  GO  TO  9000 

297  132  CALL  ALLOC(P) 

298  DO  136  1*1, NB 

299  lF(BIGd).EU,0)bO  TO  136 

300  B3d,P)a6Rd,P)«UBd)*(M0P(P)»8RP(P)) 

301  136  CONTINUE 

302  IF (3R0LD,NC« SR <P)) WRITE (XP4, 2001 )CT ,ET,8R{P),(B3d,P),I»l,NB) 

303  CALL  NEXTEV(P) 

304  GO  TO  180 

303  140  8FN2aANAXI<0.,8L{P)-8R<P)*(DT(I,P)-CT)-NC8(P)) 
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306 

307 

308 

309 

310 

311 
313 

313 

314 
313 

316 

317 

318 

319 
330 
321 
332 

323 

324 

325 

326 

327 

328 

329 

330 

331 

332 

333 

334 

333 

336 

337 

338 

339 

340 

341 

342 

343 

344 

345 

346 

347 

348 

349 

350 

351 

352 

353 

334 
353 

356 

357 

358 
339 

360 

361 
363 

363 

364 

365 

366 


sr*«sr*i+ar#2 

IF<SPM,LE,0.)GO  TO  180 
00  145  t«t,N8 
irC5E(I,P) .NE.OJGU  TO  150 
145  CONTINUE 
GO  TO  180 
ISO  CALL  SHTFAL(P) 

180  CONTINUE 

XF(SL(P),GT.M£S(P)*, 01)60  TO  185 
ESP! P)«l 
S£(NBl , P)»l 
TE(NBl,P)aOT(l,P) 

WHITC<IP2, 2001  )CT,£T, SLIP)  ♦  (8L(I , P) ,  I»1  ,»B) 

GO  TO  50 
185  ESP(P)a0 
SLTaSL(P) 

SL(P)aA"INl (SLT#  MSC(P) ) 

WRITE(IP2, 2001)CT,ET,SL(P),(BL(I,P),lai,NB) 
TEMaCT*(SL(P)»NiS(P) ) /SR (P) 

IF(TCM.LT,DT(1,P))G0  TO  190 

SE(N81,P)al 

re<N8i,P)aora,P) 

GO  TO  50 
190  SC(NBl,P)a2 
TE(NBl,P)aTEN 
GO  TO  SO 
C 

C  PROCESS  THE  ISP  DIPPING  INTO  EMERGENCY  SUPPLIES 
C 

300  WR1TC(IP1,2012)CT 

SROLDaSR (P) 

XF(SL(P).LT.NESIP)-,01)GO  TO  203 
IF(SL(P).LT.Me3ip)«.01)GO  TO  205 
203  NRITC(IP1,2U21)Ct,PN(P) 

GO  TO  9000 

205  SRTa(SL(P)-MCS(P))/(DT(l,P)-CT) 

ESP(P)al 

IF(SRT,LT,MD(P))GU  TO  210 
TE(NBl,P)aOT(l,P) 

SE(NBl,P)al 
GO  TO  50 
210  SR(P)aSRT 

SRP<P)aSR<P)-MD«<P) 

MOP(P)aMO(P)-MDM{P) 

XFCSRP(P).CE.O.)GO  TO  220 
ETa7 

00  212  Ial.NB 
BSC,P)aO. 

213  CONTINUE 

GPaP 

DO  215  Pal, 3 

XPlaJ>4*P 

IP2a4«4*P 

IP3a5«4«P 

IP4a6*4*P 

«RITC(IPl,20l9)CTfPN(JP) 

WRITECIP2,2001)CT,ET,SL(P),(BL(I,P),lai,NB) 
NRITE<IP3,20j0)CT,SL(P)#CBL(I,P),Ial#NB) 
NRITE(IP4f 2001)Cl,ET,5R(P) ,(BS(I#P),I*1#NB) 

215  CONTINUE 
GO  TO  9000 
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367 

330 

CALL  ALLOC (9) 

368 

00  335  Ial,NB 

369 

IF!BIG!I).EU.O)UO  TO  333 

370 

BS!I,P)a8RU,P)-Wtt!I)*!MDpm-SRP(P>> 

37i 

333 

CONTINUE 

373 

rtRITE(IP4,3001)lT,ET,SR(P),CBS(I,P),Xal,fcB) 

373 

TE!NBt,P}aDT!l,P) 

374 

SC(NBl,P)al 

373 

CALL  NEXTEV1P) 

376 

CO  TO  50 

377 

C 

378 

C 

PROCESS  USER  SUPPLY  LEVEL  FALLING  BELOW  SAFETY  LEVEL 

379 

C 

390 

o 

o 

m 

WRITE!IP1,2013)CT, JE 

391 

BSOLDaBSC JE,P) 

393 

IFCBLI  JC,P)  .LI.PSLC  JE,P)-.onGO  TO  303 

383 

ir<AL(JE,P).LT.BSL(JE,P)*.01)G0  TO  310 

384 

303 

WRITE!  IP1,2022)CT,«JE,PN  IP) 

383 

GO  TO  9000 

396 

310 

BP(JC.P)al, 

387 

SC(JC.P)«4 

399 

CALL  ALLOC(P) 

389 

DO  320  I«l,wB 

390 

ir(BIGU)  ,EW, 0)1*0  TO  320 

391 

8S( I , P) aBR ( I,P)"WB(IJ*(M0P(P)”6RP(P) ) 

393 

330 

CONTINUE 

393 

ZFIBSOLDt NE, BSiUErP) ) WRITE! 194, 2001 )CT,ET  , SR!P)»!B5!I*P),Ial,NB) 

394 

CALL  NEXTEV(P) 

393 

GO  TO  50 

396 

C 

397 

C 

PROCESS  USER  SUPPLY  LEVEL  REACHING  CRITICAL  LEVEL 

398 

C 

399 

400 

CONTINUE 

400 

IW>1 

401 

IF!BL(JE,P) ,LT,ttCL(JE,P)«.01)GO  TO  403 

403 

ir!BL!4E,P).LT.»»CL!JE,P)»,01>G0  TO  405 

403 

403 

WRIT£(tPl,2023)CT,JE,PN(P) 

404 

GO  TO  9000 

403 

403 

BIG(JE)aO 

406 

00  499  Pal, i 

407 

BL(JE,P)a-0, 

408 

MDQLOaMO(P) 

409 

SROLOaSR(P) 

410 

IPla344*P 

411 

IP3a4«4*P 

413 

IP3»3*4*P 

413 

IP4»6*4*P 

414 

WRITC(IP1,2014)CT,JE,PN(JP) 

413 

IF!P.CO.JP)GO  TO  409 

416 

DO  406  Ial,NB 

417 

BL! I ,P)*BL! 1 ,P)"BXG! X) *!BR!X ,P}»BS! I »P) )*!CT>TLE(P) ) 

418 

406 

CONTINUE 

419 

3L!P)aSL!P)-SR!P)*!CT*TLE!P)) 

430 

WRITE! I P2, 3001 )CT,CT,SL(P) ,!BL(Z»P) >1*1 ,NB) 

431 

409 

TLE!P)aCT 

433 

HO!P)aHO!P)-BR!JE.P) 

433 

HOP!P)«NO!P)-NDH(P) 

434 

SRP(P)«SR!P)-MDK(P) 

433 

CLOLOaCLIP) 

436 

BS!JE,P)ao, 

437 

BR! JE,P)*0, 
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I 


428 

SCCJC,P)aO 

429 

TE(JE,P)alE9 

430 

DO  410  Ial,NB 

431 

lr(BIC(I).Ea.l)<>0  TO  420 

432 

410 

CONTINUE 

433 

ETa7 

434 

JpaP 

439 

DO  416  IPal , 3 

436 

irtlP.EO.JPJGU  10  413 

437 

DO  412  Ial.NB 

438 

BLU,IP>bBL(I,IP)-(BR(I,IP)-BS{I,IP))*(CT»TLE 

439 

412 

CONTINUE 

440 

5L(IP)aSL(IP)"SH(IP)*(CT*TLE(XP)) 

441 

413 

IP1»3*4*IP 

442 

IP2«4*4*IP 

443 

IP3a5*4*IP 

444 

IP4a6*4*IP 

449 

WRITE(IP1,2018)CT 

446 

*RITE(IP2,2001}CT,ET,SL(IP) , ( BL( I , IP) , lal  ,NB) 

447 

NRITCUP3,2000)CT,SL<IP),CBL(I,IP),Ial,HB) 

448 

NRITECIP4,2001)CT,ET,SR(IP) , <BS(I,IP) ,I«1,NB) 

449 

416 

CONTINUE 

490 

GO  TO  9000 

491 

420 

lr(P.NE.JP)GO  TU  561 

492 

IF(SR(P),GE.NO(t'))GO  TO  430 

493 

CALL  ALLOC(P) 

494 

DO  425  lal.NB 

499 

IF(BIG(I).EU.O)GO  TO  429 

496 

BS(I,P)aBR(I,P)-Wb(I)*<NDP(P)-BRP(P)) 

497 

429 

CONTINUE 

499 

NRITEUP4,200l)tT,ET,SR(P),(BSU,P),XBl,NB> 

499 

CALL  NEXTEV(P) 

460 

GO  TO  480 

461 

430 

DO  439  lal'NB 

462 

BS(I*P)aBIG(I)  *BR(  I ,  P) 

461 

TE(I,P)alE9‘ 

464 

439 

CONTINUE 

469 

SR(P)aM0(P) 

466 

WRITE(IP4,2Q01)LT,ET,SRCP), CBS(I,P),I«1,NB) 

467 

IF(5RP(P).Ea,NDf'(P))G0  TO  480 

468 

SFNa(5RP<P)-«0P(P))*(0T(ifP)-CT) 

469 

CALL  SHTFAL(P) 

470 

HRITE(IP2t2001)CTfET>8L(P)>(BL(l«P)«Ial>NB) 

471 

480 

IFCNIC(P).NE,0)G0  TO  489 

472 

NRITE(IP1,2024)CT,PN(P) 

473 

GO  TO  9000 

474 

489 

TERaCT+CLOLD* ( l./SPR(P)+l,/SCL(P)+l./NSU(P) )  ■ 

479 

1  NSD<P)/<24,*6C5<P)?*N0T(P) 

476 

IF(DT(NXC(P),P) .GT. TEN J GO  TO  492 

477 

NIClaNIC(P)*l 

478 

DO  490  JaNlCl »NIC(P) 

479 

IF(DT(J,P).GE,TtN)GO  TO  492 

480 

NIC(P)aNIC(P)tl" 

481 

490 

CONTINUE 

482 

492 

CALL  RCVISE(P) 

483 

NTC(P)aNIC<$>4NC(P)M 

484 

NClaNC(P)41 

489 

DO  491  Jal.NCl 

486 

DT(NIC(P)+J(P)aDTtNICCP) #P)+J*TR(P) 

487 

DCCNIC(P)+J»P)aCL(P) 

488 

493 

CONTINUE 
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489 

IJ«0 

490 

ir<NCO.GT.NOC)GU  TO  498 

491 

MNCO 

492 

494 

DO  495  JaK,ftOC 

493 

ir'CUN( J) .EJ.JEiGO  TO  496 

494 

IJat 

495 

495 

CONTINUE 

496 

GO  TO  498 

497 

496 

NOC«NOC-1 

498 

iriJ.GT.NOOGO  10  498 

499 

DO  497  JJaJ.NOC 

500 

CUN(JJ)«CUN(Jd»l) 

SOI 

TC(JJ)«TC(Jj*l) 

502 

DO  4790  1P«1,3 

503 

CUDC JJ,IP)«CUD(JJ»1,IP) 

504 

CUP(JJ,IP)aCUP<UJ*l,IP) 

505 

4790 

CONTINUE 

506 

497 

CONTINUE 

507 

KBj 

508 

GO  TO  494 

509 

498 

CONTINUE 

510 

TEN 1»1 E9 

511 

IF(IJ,NC>0) rENl«TC(NC0) 

512 

DO  4990  IP«1,3 

513 

4990 

TC(NB2,IP)alEHl 

514 

499 

CONTINUE 

515 

IMaO 

516 

GO  TO  50 

517 

C 

518 

c 

PROCESS  CONTINGENCY  EVENT 

519 

c 

520 

500 

JEaCUN(NCO) 

521 

ICaIC+1 

522 

HDQLOaNO ( P) 

523 

SROLD-/SRCP) 

524 

MD(P)aND(P)«BH(JE,P)»CUD{NCO,P) 

525 

BP<JE,PlaCUD(NCU,P) 

526 

BPOLDbBIP(JE,P) 

527 

BIP( JE,P)«CUP(NCO,P) 

528 

IF(5E(JE,P).NE.4)BP(JE,P)aBIPCJE 

529 

TECNB2,P)»1C9 

530 

ir(IC.NE.3)G0  TO  504 

531 

ICaO 

532 

NCOaNCO+1 

533 

NC01»NC0 

534 

IFCNCOl.GT.NOOOO  TO  503 

535 

DO  501  NaNCOl »NUC 

536 

JTaCUN(N) 

537 

irCBIG(JT) .NE.OJGO  TO  502 

538 

NCOaNCO+l 

539 

501 

CONTINUE 

540 

502 

iriNCO.GT.NOOGU  TO  503 

541 

DO  5020  KPalf3 

542 

TE(NB2,KP)aTC(NtO) 

543 

5020 

CONTINUE 

544 

GO  TO  504 

545 

503 

DO  5030  KP«l,3 

546 

TE(NB2, NPJalEV 

547 

5030 

CONTINUE 

548 

504 

CLOLOaCUP) 

549 

ir(HOCP)-MDOLO) 560 ,550,520 
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550 

520 

CALL  REVISE(P) 

551 

*RITE(IPl,20lS)LT»JE 

552 

WRITE(IP2,2O01)CT,ET,SL(P),(BL(I,P),I«l,NB) 

553 

IF(ESP(P).N£,0)i.0  TO  542 

554 

SR(P)»NO(P> 

555 

BS(JE,P)«BR(JE,P) 

556 

WRITEUP4,2601)CT,ET,SR(P),  (BSCI,P)  ,I«1,NB) 

557 

522 

CONTINUE 

558 

TFA«CT4SCC(P)*ll./SPR(P)4i,/SCL(P)4l./N3U(P))  ♦ 

559 

1 

MS0(P>/(24,»5CS(P))4*0T(P) 

560 

NIC(P)»0 

561 

TEK«CT4CL0L0«(l./SPR{P)*l./SCL{P)4l./N5U(P)>  4 

562 

1 

N50(P)/(24,*5CS(P))4N0T(P) 

563 

00  525  J«1,NTC(P) 

564 

IF(DT( J,P) ,GE.TtM)GO  TO  526 

565 

NIC(P)«NIC(P)41 

566 

525 

CONTINUE 

567 

526 

TSA«0T(NIC(P)4l#P) 

568 

CLP*0C(NIC(P)41 >P) 

569 

CAR»CLP4(ND(P)-ND0LD)*{TSA-CT) 

570 

TEM«CC»R-N0(P)*IT5A-Tr*))/5CCCP) 

571 

ITE«»INT(TE«) 

572 

RENaTEM-l.viTbM 

573 

IF ( REM , 5T , 0 • ) IT£M*IT£N4l 

574 

TLA»rs»-(CAR-ITtN*6CC{P) )/ND(P) 

575 

IFCREN.GT.O.JGO'TO  529 

576 

DO  528  J*1,ITEN 

577 

DT(NICCP)4j,P)«iFA4(J.l)*,001 

578 

DC(NIC(P)4j,PJ»acC(P) 

579 

528 

CONTINUE 

580 

NIC(P)»NIC(P)4ITEN 

581 

GO  TO  536 

582 

529 

IF(ITEM,GT.1}G0  TO  531 

583 

IF(NIC(P).EU.0)Oa  TO  530 

584 

TL»DI(NIC(P)*P) 

585 

GO  TO  533 

586 

530 

TL»CT-(NSC(P)-5L(PJ)/N0(P1 

587 

GO  TO  533 

588 

531 

IT1-ITEN-1 

589 

DO  532  J»1 » 1T1 

590 

DT(NIC(P)4J,P)«TFA4(J«1>*,001 

591 

DC(NIC(P)4J,P)«SCC(P) 

592 

532 

CONTINUE 

593 

TL»TFA 

594 

533 

IF((TLA-TL).GE,TR(P))GO  TO  534 

595 

DT(NIC(P)4lTEN,P)»TLA 

596 

DC(NIC(P)*ITEN,P)»5CC(P) 

597 

GO  TO  535 

598 

534 

TEN«AMAX1(TL4TRIP)>TFA) 

599 

DT(NIC(P)4lTEM,f )»TE« 

600 

0C(NIC(P)4lTCM,P)»5CC(P)-N0(P)*(TLA-TEN) 

601 

535 

NIC(P)»NIC(P)4ITEN 

602 

536 

NCI *NC { P) 4l 

603 

DO  537  J*1 , NCI 

604 

DT(NIC(P)4j,P)»0TlNIC(Pl,P)4j*TR(P) 

60S 

DC(NICCP)4j,P)»CL(P) 

606 

537 

CONTINUE 

607 

NTCCP)«NIC(P)4NC(P)«1 

608 

XF(ESP(P)(Ea.l)GO  TO  539 

609 

TEN»CT4{3L(P)-NtSlP))/RD(P) 

610 

IFCTEN.GE,DT(l,PnGO  TO  538 
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611 

SCCNB1 ,P)a2 

612 

TE(NBl,P)«TfcM 

613 

GO  TO  50 

614 

538 

SE(N81 ,P)«1 

615 

TECN81,P)«Dm,P) 

616 

GO  TO  50 

617 

539 

SE(NB1,P)«1 

618 

TE(NBl,P)«Ola,P) 

619 

GO  TO  50 

620 

542 

SRT»<SL(P)-*CSCt*)l/(DT<l,P)«CT) 

621 

IF(SRT.LT.MO(P))GU  TO  545 

622 

SR(P)«ND<P) 

623 

BS(JE,P)»BR(JE,P) 

624 

WRITEaP4,2601)tT,ET,SR(P>«(BS(X,P),lBl,NB) 

625 

GO  TO  522 

626 

545 

SR  (  P ) «SRT 

627 

SRP(P)«SR(PJ-MOK(P) 

628 

MDP(P)«ND(P)*MDK(H) 

629 

CALL  ALLOCCP) 

630 

DO  548  1*1 » NB 

631 

IF(BIGd) .EQ.OJGO  TO  548 

632 

BS(I,P)»BR(X.P)-Rba}*(MOP(P)-SRP(P)) 

633 

548 

CONTINUE 

634 

WRITE(IP4,2001)CT,ET,SR(P).(BS(I,P),X>1,NB) 

635 

CALL  NEXTEVfPJ 

636 

GO  TO  522 

637 

550 

IF(8IP(JE,P),EQ.BP0LD)Ga  TO  50 

638 

NRITEaPl,20l5)tT,JE 

639 

WRlTE(lP2,200l)£T,ET,SL(P),(8b(I,P),I*l,NB) 

640 

IF(ESP(P),Eg,0)i.O  TO  50 

641 

IFCSRCP).EQ.MU(H) JCO  TO  50 

642 

IF(SE(JE,PJ.E0,4)G0  TO  50 

643 

SRPCP)»3R(P)»MDKCP) 

644 

NOP ( P ) »ND  (  P) "MQR ( P ) 

645 

CALL  ALLOC ( P) 

646 

00  555  1*1  » NB 

647 

IFCSIGd)  .EU.OJUO  TO  555 

648 

BSd,P)«BR(I,P)-NBd)*<N0P(P)-5RP(P)) 

649 

555 

CONTINUE 

650 

NRITEdP4,2001)CT,ET',3R(P),(BSd,P),Ial,NB) 

651 

CALL  NEXTEVIP) 

652 

GO  TO  50 

653 

560 

CONTINUE 

654 

NRITEdPl,20l5)tT,JE 

655 

561 

CALL  REVI5ECPJ 

656 

NRITEdP2,2U01)LT,ET,SL(P),  (BL(I,P),I»1/NB) 

657 

IFtESP(P).NE,0)&0  TO  585 

658 

8R(P)*M0(P) 

659 

BS(JE,P)nBR(JE,P) 

660 

NRITEdP4,2001)CT,ET,SR(P),CB5d,P),I»l,NB) 

661 

562 

CONTINUE 

662 

NIC<P)»0 

663 

TEN*CT»CLOLU*( 1 »/SPR ( ?)♦! ,/SCL(P)*l«/NSU(P) : 

664 

1  NSD(P)/(24,*SCS(P))*N0T(P) 

665 

00  564  J«l,NTC(P) 

666 

IF(0T(J,P).0E.ItN)GO  TO  565 

667 

NJC(P)«NIC(P)*1 

668 

564 

CONTINUE 

669 

565 

IF<NIC(PJ.EU,0)«0  TO  566 

670 

TL»OT{NIC(P),P)' 

671 

TN«OI(NIC<P)*t,P) 
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672 

CLIaOC(NIC(P)M*P) 

67  J 

00  TO  568 

674 

566 

TL»CT 

675 

TNaDTfl ,P) 

676 

CLX»0C(1,P) 

677 

568 

NXC(P)«NICCP)*1 

678 

DELT»TN-TL 

679 

SOr«CMOOLD-*OCPn*DeLT 

680 

ir  (  nic<  p).  cu.  i )  Xl*ct-(nsc  (P) -sup)  )/mdcp) 

641 

TPA»TN*(SOr+SCC(P)-CLI)/HO<P) 

682 

IF(  (TP  4 -Tli)  .GT, TRIP))  GO  TO  572 

68} 

dtcnic<p) ,p)«tpa 

684 

DC(MIC(P),P)»SCC(P) 

685 

GO  TO  580 

686 

572 

TFAa(CT+<SCC(P)“TPA*ND(P))*(lt/5PR(P)*l t/SCL(P)+l ./MSU(P)) 

687 

4SD(P)/(24.*3CS(P))>80T(P)) 

686 

/U.-M0<P)*<1.?SPR<P)*1./3CL<P)M./MSU(P>)> 

689 

ir((Tr*-TL).GT,IR(P))GO  TO  574 

690 

DT<NIC(P),P)aTL*TR(P) 

691 

DC(NlC(P),P)aSCC(P)-<TPA-?R(P)-TL)*KDCP) 

692 

GO  TO  580 

693 

574 

DT(NIC(P),P)>TM 

694 

DC(NIC(P),P)»SCC(P)-(TP»-Trfc)*MDCP) 

695 

580 

NClaNC ( P ) ♦! 

696 

NTC(P)«NIC(P)*NC(P)4l 

697 

DO  582  J«1,NC1 

698 

DKNIC  (P)  *J/  P)«DT(  NIC(P)  >P)+G*TR(P) 

699 

DC(NIC(P)*J,P)aCL<P) 

700 

582 

CONTINUE 

701 

ir(ESP(P),Nt,0)GO  TO  584 

702 

TEN»CT*(SL(P) -Mfc3(P) )/ND(P) 

703 

ir(TEN,GE.DT(l,P))GO  TO  584 

704 

SE(Nai,P)>2 

705 

TE(NBl,P)aTEM 

706 

irXIW.EO.USO  TU  499 

707 

GO  TO  50 

708 

584 

5£(NB! ,  P)al 

709 

TE(NBl,P)»Dia,P) 

710 

ir<I«.E0.1)G0  TU  499 

711 

GO  TO  50 

712 

585 

3RT«(Sli(P)"NCS<P)  )/(DT< 1  »P)-CT) 

713 

ir(SR(p) .ge.muoudjgo  to  590 

714 

IfCSRT.GE.NOCP) JGO  TO  588 

715 

SR(P)»SRT 

716 

SRP(P)aSR(P)-MOM(P) 

717 

N0P(P)aND(P)-M0H(P) 

718 

CALL  ALLOC(P) 

719 

DO  587  I«1,NB 

720 

XF(BIG(I).EUaO)GO  TO  587 

721 

BS( I «P) aBR( I » P)-WB ( I ) *(HDP(P)-3RP(P)  ) 

722 

587 

CONTINUE 

723 

NRITE(IP4,2001)CT,ET,SR(P), (BSCI.P) ,I«l,NB) 

724 

CALL  NEXTEV(P) 

725 

GO  TO  562 

726 

588 

DO  589  Ial,NB 

727 

8S(I,P)bBIGCI)*BR(I,P) 

728 

TE(I,P)alE9 

729 

589 

CONTINUE 

730 

ir(8RT.GT,MD(P))G0  TO  590 

731 

3R(P)aN0(P) 

732 

BS(JE,P)aBR(JE,P) 
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733 

WRITE<IP4,2001)CT,ET,3R(P} ,  !BS !  I , P) , I»1 ,NB) 

734 

GO  TO  562 

735 

590  SR!P)«WO!P) 

736 

BS!JE,P)»BR!JE,P) 

737 

WRIT£!IP4,200i)CT,£T,SR!P),!BStI,P),I»l,NB) 

736 

sr««(SRT-SR(P))*(OTa,P)-CT) 

739 

740 

DO  592  !■! #NB 

741 

IF(SE(I,P).NE.OJGQ  TO  595 

742 

592  CONTINUE 

743 

GO  TO  562 

744 

595  CALL  SHTFALCP) 

745 

WRITE!  IP2,2001)CT#ET, SLIP). (BLt I ,P),I«t,NB) 

746 

GO  TO  562 

747 

C 

748 

C 

PROCESS  SCHEDULED  PRINT  OUT 

749 

C 

750 

600  TE(NB3,PJ«CT4TP 

751 

752 

ir(TECNS3,P),(jT.TDUR)G0  TO  610 

753 

TE!HB3,P)»TBUH 

754 

SE!NB3,P>»7 

755 

610  WRITE(IP3,2000)CT,SL(P),(BL(I,P),I»1,NB> 

756 

GO  TO  50 

757 

C 

758 

C 

PROCESS  SCHEDULED  RUN  TERMINATION 

759 

C 

760 

700  DO  710  P»1 t 3 

761 

IP1»3*4*P 

762 

IP2»4*4«P 

763 

IP3»S*4«P 

764 

IP4«6*4*P 

765 

IFtP.EO.JPJGO  TU  708 

766 

DO  702  1*1, «B 

767 

8L!  I , P)*8L< I #P) *<8R( I ,P)»B3( I , P) 7* £CT“TLE(P) ) 

768 

702  CONTINUE 

769 

3L(P)«SL(PJ-SR<P)*<CT-TLB<P)) 

770 

WRITE(IP2,200l)CT»ET»SL(P),(BL(I*P)fI"l»N8) 

771 

708  WRITCCIPl,2017)er 

772 

WRITE! IP3, 2000 )CT,3L(P),(BL( I, P) ,I"t,NB) 

77  J 

WRITE(IP4,2001)Cr,ET,SR(P)#<BS(I,P),I»t,N8) 

774 

710  CONTINUE 

775 

GO  TO  9000 

776 

900  WRITE! IP1 <2025} 

777 

9000  CONTINUE 

778 

C 

779 

REWIND  9 

780 

REWIND  9 

781 

REWIND  10 

782 

REWIND  It 

783 

REWIND  12 

784 

REWIND  13 

785 

REWIND  14 

786 

REWIND  15 

787 

REWIND  16 

788 

REWINO  17 

789 

REWIND  18 

790 

9100  R£AD!8#l003#ERRR9200f|NDR9300)!NK(K)>K»l«l32) 

791 

WRlTE!7'iOOS)!N*tK),Ml,132> 

792 

GO  TO  9100 

793 

9200  REAO 1 9 r 1005 #CRR"9 300 # ENO»9300 ) (NR!K)»N»1»132) 
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794  *RITE(7,100SHM«(K),Kal,132) 

795  CO  TO  9200 

796  9300  READ(tO, 1005, £RKa9400,ENDa9400)(HK(K),Kat, 132) 

797  NRITE(7,1005)(NA(K),Kal,132) 

796  GO  TO  9300 

799  9400  READ(lt,1005,ERKa9401,ENDa9401)(NK(K),Kal,132) 

900  NRIT£(7,1005)(N*(K),Kat,t32) 

801  GO  TO  9400 

802  9401  READ(t2, 1005, ERHa9402,ENDa9402)(NK(K),Kal, 132) 

803  *RIT£(7,10Q5)(N*(K),M1,132) 

904  GO  TO  9401 

803  9402  REA0(13, 1003, ERHa9403,ENDa9403)(MK(K),Kal, 132) 

906  rfRXTE(7,1005)(Nrt(K),Kal,132) 

807  GO  TO  9402 

908  9403  REA0C14, 1003, ERHa9404,ENDa9404)(MK(K),Kal, 132) 

909  «RITE(7,1003)<MK(K),Kal,132) 

810  GO  TO  9403 

911  9404  READOS, 1005, ERNa9403,ENDa9405> (NK(K> ,Kal , 132) 

812  4RXTE(7,1005)(Hli(K),Kal,132) 

813  GO  TO  9404 

814  9403  REA0C16, 1003, ERHa9406, CR0a9406) (MKCK)  ,Kal, 132) 

813  MRITE(7,1005)(NK(K),Kal,132) 

916  GO  TO  9403 

917  9406  REA0C17, 1003, GRKa9407,EK0a9407)(RK(K),Kal, 132) 

818  MRITC(7,1005)(M(K),Kat,132) 

819  GO  TO  9406 

820  9407  RCAOCIS, 1005, ERKa9900,ENOa9900)(NK(K),Kal, 132) 

821  WRITE(7,100S)<N*(K),Kal,132) 

922  GO  TO  9407 

823 

824 
823 
826 

827 

828 

829  9900  STOP 

830  ENO 

831  SUBROUTINE  HEVXSE(P) 

832  COMMON  /BL0CK1/  TCN, NSC( 3 ) ,NE3 ( 3 ) , NO ( 3 ) ,SCC( 3 ) ,TR ( 3) , 

833  1  CL(3),TCY(3>, TCP, 3PR(3), 30.(3), 

934  2  MSU(3) , NC(3) 

933  REAL  MD,M3C,MSU,ME3 

836  INTEGER  P 

837  TCNa(M3C(P)-NCS(P))/N0(P) 

831  TEMaSCC(P)/MO(pJ 

839  Xr<TCM,GT.TCHjGO  TO  10 

940  TR(P)aTEN  -  „ 

941  Ct>(P)aSCC(P) 

942  TCPaTCT(P) 

943  GO  TO  20 

844  10  TR(P)aTCN 

943  Cl»(P)aTR(P)*ND(P) 

946  TCPaICY(P)-(3CC(P)-Cl(P))*<l,/SPR(P)*l,/Sd,(P>M,/NSU(P)) 

847  20  TElaICP/TR(9) 

941  NC(P)alNTtTEN) 

949  RCMaTCN-l.«NC(P) 

930  Xr(REN,GT.O.)NC<P)aNCCP)M 

931  RETURN 

932  ENO 

933  SUBROUTINE  NEXTEV(P) 

934  COMNOM  /SI.0CK2/NB,  9X0(10)  ,  8E  (13,3),  TE  (13,3),  SL  (10,3),  B3t,(10, 3), 
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8SS 

1  BMLCtO, J),BCL( 10, 3),BR( 10,3), 8IR(10,3),B3 (10,3), BP (10,3), 

856 

2  BIP(10,3),«B<10),3L(3),SrM,CT 

857 

INTEGER  5E,8IG,P 

858 

DO  10  1*1 ,  N8 

859 

ir(BIGU). Ed. 0)1.0  TO  10 

860 

ir(SE(I,P>,EQ.4JCO  TO  5 

861 

3E(I,P)*3 

862 

TE(I,P)*CT*(BL(I,P)-83LU,P))/CBR(l,P)-BS<I,P)> 

863 

GO  TO  10 

864 

5 

TE(I,P)*CT*<aL<i,P)-BCL(X,P))/(BR(I,P)-B3(I,P>) 

865 

10 

CONTINUE 

866 

RETURN 

867 

END 

868 

SUBROUTINE  ALLOC(P) 

869 

COMMON  /SLOCK2/'NB,BIG(lO),SE(ll,S),TE(13,3),BL<10,3),B3LClO,3) , 

870 

1  BMLUO. J),BCL( 10,3), BR( 10,3), BXR( 10,3), 88(10,3),  BP(  10. 3), 

871 

2  BIP(10,3),»8(10),SL(3),SPM,CT 

872 

INTEGER  SE,B1G,P 

873 

DIMENSION  B( 10) 

874 

PROat, 

875 

00  10  Ial,NB 

876 

irtBIGCD.EQ, 0)(.0  TO  10 

877 

B(I)asp(I,P)/8ft?I,P) 

878 

PROaPRO*B( I ) 

879 

10 

CONTINUE 

880 

SUMaO, 

881 

DO  20  Ial,NB 

882 

IF(BIG(I).EU,0)(.0  TO  20 

883 

WB(I)aPRO/B(I) 

884 

SUM*  SUM4*a<I) 

885 

20 

CONTINUE 

886 

DO  30  Ial,NB 

887 

irCBIGCI)  ,EQ,0)(.O  TO  30 

888 

WB(I)aNB(I)/3UM~ 

889 

30 

CONTINUE 

890 

RETURN 

891 

END 

892 

SUBROUTINE  SHIPAL(P) 

893 

COMMON  /BLOCK 2/  NB,BIG(t0),3C(13,3),IE(13,3),BL(10,3),B3L(10,3), 

894 

1  BML(10,3),BCL(10,3),BR(10,3),BIR(10,3),BS(10,3),BP(10,3), 

895 

2  BIP(10,3),*B(10),SL(3),SPM,CT 

896 

INTEGER  SC,B1g;P 

897 

DIMENSION  3F(10)‘ 

898 

00  10  Ial,N8 

899 

IP(BIG(I).EG,0)LO  TO  10 

900 

ir(3E(I,P). £0,4/60  TO  20 

901 

10 

CONTINUE 

902 

GO  TO  80 

903 

20 

SSPaO, 

904 

00  30  1*1 , NB 

90S 

ir<SE(I,P).NE.4)G0  TO  29 

906 

SF(X)aft3L(I,P)»«L(X,P) 

907 

S3F*SBFtSF(I) 

908 

GO  TO  30 

909 

29 

SP(I)*0. 

910 

30 

CONTINUE 

911 

IP(SPN.GC.SSr)GU  TO  50 

912 

DO  45  Ial,N8 

913 

aL<i,P)aBL(i,P)+sr<:)*Brx/ssr 

914 

45 

CONTINUE 

913 

3l(P)a8L(P)-SFN 
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918 

RETURN 

917 

90 

00  60  lal,N6 

918 

rr(srci).e<j.o.)<*o  to  60 

919 

920 

SFNaSFM-SFCi) 

921 

SUP)»SL(P)*Sf  (1) 

922 

60 

CONTINUE 

923 

ir(SPN,LE,0.)RETURN 

924 

00  70  X ■  1  * N tt 

929 

IFCSE(I,P) .NE.4JC0  TO  70 

926 

SE(l,P)a3 

927 

BP(I,P)aBIPCI,PJ 

921 

70 

CONTINUE 

929 

80 

ssrao. 

930 

00  90  lal'NB 

931 

IF(3E(I,P).NE.3;C0  TO  89 

932 

SF(I)aBNt,(I'P)-*(<<X,P) 

933 

SSF*SSF4SF(I) 

934 

CO  TO  90 

939 

89 

SF(I)a0. 

936 

90 

CONTINUE 

937 

IF(SFN.OT.SSF)QU  TO  120 

938 

00  110  1*1  *  N8 

939 

IF(3F(I).Ea.O,)CO  TO  110 

940 

BI>(I»P)aBNti(X>P3 

941 

SE(I,P)aO 

942 

S0(P)a3L{P)-SF(l) 

943 

110 

CONTINUE 

944 

RETURN 

949 

120 

00  130  lai,NB 

946 

IF(BICCI).EJ.0)<.0  TO  130 

947 

BL(I,P)aBli(I.P)+3F(I)*3FN/35F 

948 

130 

CONTINUE 

949 

SL(P)*SL<P)-SFN 

990 

RETURN 

991 

END 
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